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K.  Appendix  1. 
COCOMO  Summary 
USC-CSE  COCOMO  Team 


1  Introduction 

COCOMO  II  is  a  parametric  model  for  software  cost/estimation. 

The  two  main  elements  of  the  COCOMO  II  strategy  are; 

•  Preserve  the  openness  of  the  original  COCOMO  with  all  of  its  relationships  and  algorithms 
publicly  available. 

•  Key  the  inputs  and  outputs  of  the  COCOMO  II  submodels  to  the  level  of  information 
available. 

All  of  its  interfaces  are  designed  to  be  public,  well-defined,  and  parametrized  so  that 
complementary  preprocessors  (analogy,  case-based,  or  other  size  estimation  models),  post¬ 
processors  (project  planning  and  control  tools,  project  dynamics  models,  risk  analyzers),  and 
higher  level  packages  (project  management  packages,  product  negotiation  aids)  can  be  combined 
straightforwardly  with  COCOMO  II. 

2  Overall  Model  Definition 

2.1  COCOMO  II  Models  for  the  Software  Marketplace  Sectors 

The  COCOMO  II  capability  for  estimation  of  Application  Generator,  System  Integration  or 
Infrastructure  developments  is  based  on  two  increasingly  detailed  estimation  models  for  sub¬ 
sequent  portions  of  the  life  cycle.  Early  Design  and  Post-Architecture. 

2.1.1  COCOMO  II  Model  Rationale  and  Elaboration 

This  mix  of  models  rests  on  three  primary  premises:  First,  current  and  future  software  projects 
will  be  tailoring  their  processes  to  their  particular  process  drivers.  These  process  drivers  include: 
COTS  or  reusable  software  availability;  degree  of  understanding  of  architectures  and 
requirements;  market  window  or  other  schedule  constraints;  size;  and  required  reliability  (see 
[Boehm  1989,  pp.  436-37]  for  an  example  of  such  tailoring  guidelines).  Second,  the  granularity 
of  the  software  cost  estimation  model  used  needs  to  be  consistent  with  the  granularity  of  the 
information  available  to  support  software  cost  estimation.  Third,  COCOMO  II  does  not  produce 
point  estimates  of  software  cost  and  effort,  but  rather  ranges  estimates  tied  to  the  granularity  of 
the  estimation  inputs. 

With  respect  to  process  strategy.  Application  Generator,  System  Integration,  and  Infrastructure 
software  projects  will  involve  a  mix  of  three  major  process  models.  The  appropriate  models  will 
depend  on  the  project  marketplace  drivers  and  degree  of  product  understanding. 

The  Early  Design  model  involves  exploration  of  alternative  software/system  architectures  and 
concepts  of  operation.  At  this  stage,  not  enough  is  generally  known  to  support  fine-grain  cost 
estimation.  The  corresponding  COCOMO  II  capability  involves  the  use  of  function  points  and  a 
course-grained  set  of  7  cost  drivers,  (e.g.  Two  cost  drivers  for  Personnel  Capability  and  Per- 
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sonnel  Experience  in  place  of  the  6  COCOMO II  Post-Architecture  model  cost  drivers  covers 
various  aspects  of  personnel  capability,  continuity,  and  experience.) 

The  Post-Architecture  model  involves  the  actual  development  and  maintenance  of  a  software 
product.  This  stage  proceeds  most  cost-effectively  if  a  software  life-cycle  architecture  has  been 
developed;  validated  with  respect  to  the  system's  mission,  concept  of  operation,  and  risk;  and 
established  as  the  framework  for  the  product.  The  corresponding  COCOMO  II  model  has  about 
the  same  granularity  as  the  previous  COCOMO  and  Ada  COCOMO  models.  It  uses  source 
instructions  and/or  function  points  for  sizing  with  modifiers  for  reuse  and  software  breakage,  a 
set  of  17  multiplicative  cost  drivers,  and  a  set  of  5  factors  determining  the  project's  scaling 
exponent.  These  factors  replace  the  development  modes  (Organic,  Semidetached,  or  Embedded) 
in  the  original  COCOMO  model,  and  refine  the  four  exponent-scaling  factors  in  Ada  COCOMO. 

To  summarize,  COCOMO  II  provides  the  following  three-stage  series  of  models  for  estimation  of 
Application  Generator,  System  Integration,  and  Infrastructure  software  projects; 

1.  The  earliest  phases  or  spiral  cycles  will  generally  involve  prototyping,  using  the  Application 
Composition  model  capabilities.  The  COCOMO  II  Application  Composition  model  supports 
these  phases,  and  any  other  prototyping  activities  occurring  later  in  the  life  cycle. 

2.  The  next  phases  or  spiral  cycles  will  generally  involve  exploration  of  architectural  alternatives 
or  incremental  development  strategies.  To  support  these  activities,  COCOMO  II  provides  an 
early  estimation  model  called  the  Early  Design  model.  This  level  of  detail  in  the  model  is 
consistent  with  the  general  level  of  information  available  and  the  general  level  of  estimation 
accuracy  needed  at  this  stage. 

3.  Once  the  project  is  ready  to  develop  and  sustain  a  fielded  system,  it  should  have  a  life-cycle 
architecture,  which  provides  more  accurate  information  on  cost  driver  inputs,  and  enables  more 
accurate  cost  estimates.  To  support  this  stage,  COCOMO  II  provides  the  Post-Architecture 
model. 

2.2  Development  Effort  Estimates 

In  COCOMO  II  effort  is  expressed  as  Person  Months  (PM).  All  effort  equations  are  presented  in 
“COCOMO  II  Model  Definition  Manual.”  A  person  month  is  the  amount  of  time  one  person 
spends  working  on  the  software  development  project  for  one  month.  This  number  is  exclusive  of 
holidays  and  vacations  but  accounts  for  weekend  time  off.  The  number  of  person  months  is 
different  from  the  time  it  will  take  the  project  to  complete;  this  is  called  the  development 
schedule.  For  example,  a  project  may  be  estimated  to  require  50  PM  of  effort  but  have  a  schedule 
of  1 1  months. 

Equation  2.1  is  the  base  model  for  the  Early  Design  and  Post-Architecture  cost  estimation 
models.  The  inputs  are  the  Size  of  software  development,  a  “constant,”  A,  and  a  scale  factor,  B. 
The  size  is  in  units  of  thousands  of  source  lines  of  code  (KSLOC).  This  is  derived  from  estimat¬ 
ing  the  size  of  software  modules  that  will  constitute  the  application  program.  It  can  also  be  esti¬ 
mated  from  unadjusted  function  points  (UFP),  converted  to  SLOC  then  divided  by  one  thousand. 
Procedures  for  counting  SLOC  or  UFP  are  explained  in  the  chapters  on  the  Post-  Architecture 
and  Early  Design  models  respectively. 
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The  scale  (or  exponential)  factor,  B,  accounts  for  the  relative  economies  or  diseconomies  of  scale 
encountered  for  software  projects  of  different  sizes  [Banker  et  al  1994a].  The  constant  ,  A,  is 
used  to  capture  the  multiplicative  effects  on  effort  with  projects  of  increasing  size 

2.3  Software  Economies  and  Diseconomies  of  Scale 

Software  cost  estimation  models  often  have  an  exponential  factor  to  account  for  the  relative 
economies  or  diseconomies  of  scale  encountered  in  different  size  software  projects.  The 
exponent,  B,  in  Equation  2. 1  is  used  to  capture  these  effects. 

If  j?  <  1.0,  the  project  exhibits  economies  of  scale.  If  the  product's  size  is  doubled,  the  project 
effort  is  less  than  doubled.  The  project's  productivity  increases  as  the  product  size  is  increased. 
Some  project  economies  of  scale  can  be  achieved  via  project-specific  tools  (e.g.,  simulations, 
testbeds)  but  in  general  these  are  difficult  to  achieve.  For  small  projects,  fixed  start-up  costs  such 
as  tool  tailoring  and  setup  of  standards  and  administrative  reports  are  often  a  source  of  economies 
of  scale. 

If  B  =  1.0,  the  economies  and  diseconomies  of  scale  are  in  balance.  This  linear  model  is  often 
used  for  cost  estimation  of  small  projects.  It  is  used  for  the  COCOMO II  Applications 
Composition  model. 

If  5  >  1.0,  the  project  exhibits  diseconomies  of  scale.  This  is  generally  due  to  two  main  factors: 
growth  of  interpersonal  communications  overhead  and  growth  of  large-system  integration 
overhead.  Larger  projects  will  have  more  personnel,  and  thus  more  interpersonal  communications 
paths  consuming  overhead.  Integrating  a  small  product  as  part  of  a  larger  product  requires  not 
only  the  effort  to  develop  the  small  product,  but  also  the  additional  overhead  effort  to  design, 
maintain,  integrate,  and  test  its  interfaces  with  the  remainder  of  the  product. 

2.3.1  Basis  of  Economy  and  Diseconomy  of  Scale 

Historically,  project  and  target  platform  environment  impact  the  diseconomies  of  scale  in 
software  development.  Embedded-software  projects  tended  to  be  more  unprecedented,  requiring 
more  communication  overhead  and  complex  integration,  and  less  flexible,  requiring  more 
communications  overhead  and  extra  effort  to  resolve  issues  within  tight  schedule,  budget, 
interface,  and  performance  constraints.  Conversely  communications  overhead  and  integration 
overhead  can  be  reduced  significantly  by  early  risk  and  error  eliminationj  by  using  thorough, 
validated  architectural  specifications;  and  by  stabilizing  requirements. 

As  a  result  COCOMO  II’s  model  added  into  the  scale  factors  for  the  architecture  and  risk  factors 
as  a  single  factor.  The  COCOMO  II  model  also  has  a  process  maturity  factor  based  on  the 
Software  Engineering  Institute  (SEI)  definition.  The  model  also  includes  precedentedness  and 
flexibility  factors  and  a  Team  Cohesiveness  factor  to  account  for  the  diseconomy-of-scale  effects 
on  software  projects  whose  developers,  customers,  and  users  have  difficulty  in  synchronizing 
their  efforts. 

2.3.2  Scaling  Drivers 

Equation  2.2  defines  the  exponent,  B,  used  in  Equation  2.1 .  Table  2-1,  which  follows  the 
discussion  of  the  arithmetic,  shows  the  rating  levels  for  the  COCOMO  II  scale  drivers.  The 
selection  of  scale  drivers  is  based  on  the  rationale  that  they  are  a  significant  source  of  exponential 
variation  on  a  project’s  effort  or  productivity  variation.  Each  scale  driver  has  a  range  of  rating 
levels,  from  Very  Low  to  Extra  High.  Each  rating  level  has  a  weight,  W,  and  the  specific  value  of 
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the  weight  is  called  a  scale  factor.  A  project's  scale  factors,  fVj,  are  summed  across  all  of  the 
factors,  and  used  to  determine  a  scale  exponent,  B,  via  the  following  formula: 

B  =  .91  +  0.01x2]ff.  (2.2) 

[Data  for  following  examples  in  “CII98-Official+Anal.xls”]For  example,  if  scale  factors  with  an 
Extra  High  rating  are  each  assigned  a  weight  of  (0),  then  a  100  KSLOC  project  with  Extra  High 
ratings  for  all  factors  will  have  JWi  =  0,  B  =  0.91,  and  a  relative  effort  E  =  100-^^  =  66  PM.  If 
scale  factors  with  Very  Low  rating  are  each  assigned  a  weight  of  (5),  then  a  project  with  Very 
Low  (5)  ratings  for  all  factors  will  have  2W{  =  31.62,  B  =  1.226  and  a  relative  effort  E  =  283.4 
PM.  This  represents  a  large  variation,  but  the  increase  involved  in  a  one-unit  change  in  one  of 
the  factors  is  only  about  4.7%. 

Table  2-1:  Scale  Factors  for  COCOMO II  Early  Design  and  Post- Architecture  Models 


Scale  Factors 

m 

Very  Low 

Low 

Nominal 

High 

Very  High 

Extra  High 

PREC 

thoroughly 

unprece¬ 

dented 

largeiy 

unprece¬ 

dented 

somewhat 

unprece¬ 

dented 

Generally 

familiar 

largely  famil¬ 
iar 

thoroughly 

familiar 

FLEX 

rigorous 

occasional 

relaxation 

some 

relaxation 

some 

conformity 

general 

goals 

mm 

little  (20%) 

some  (40%) 

often  (60%) 

generally 

(75%) 

mostly  (90%) 

full  (100%) 

TEAM 

very  difficult 
interactions 

some  difficult 
interactions 

basically 

cooperative 

interactions 

largely 

cooperative 

highly 

cooperative 

seamless 

interactions 

Weighted  average  of  “Yes”  answers  to  CMM  Maturity  Questionnaire 

2.3.3  Values  for  Scale  Factors 

Section  4.0  (page  29)  contains  the  numeric  values  for  the  COCOMO  11-1998  Scale  Factors.  The 
same  values  are  used  for  the  Early  Design  and  the  Post  Architecture  models.  The  rest  of  this 
section  discusses  the  scale  factors  in  terms  of  their  nominal  levels. 

2.3.3.1  Precedentedness  (PREC)  and  Development  Flexibility  (FLEX) 

Table  2.2  maps  project  features  onto  the  Precedentedness  and  Development  Flexibility  scales. 
This  table  can  be  used  as  a  more  in  depth  explanation  for  the  PREC  and  FLEX  rating  scales  given 
in  Table  2-1. 


'  %  significant  module  interfaces  specified,%  significant  risks  eliminated. 
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Table  2-2:  Scale  Factors  Related  to  PREL  and  FLEX 


Feature 

Nominal  /  High  Extra  High 

Precedentedness  (PREC)  1 

Organizational  understanding  of  product 
objectives 

General 

Considerable 

Thorough 

Experience  in  working  with  related 
software  systems 

Moderate 

Considerable 

Extensive 

Concurrent  development  of  associated 
new  hardware  and  operational 
procedures 

Extensive 

Moderate 

Need  for  innovative  data  processing 
architectures,  alaorithms 

Considerable 

Some 

Minimal 

1  Development  Flexibility  (FLEX) 

Need  for  software  conformance  with  pre- 
established  requirements 

Full 

Considerable 

Basic 

Need  for  software  conformance  with 
external  interface  specifications 

Full 

Considerable 

Basic 

Premium  on  early  completion 

High 

Medium 

Low 

2.3.3.2  Architecture  /  Risk  Resolution  (RESL) 

This  factor  combines  two  scale  factor  concepts,  “Design  Thoroughness  by  Product  Design 
Review  (PDR)”  and  “Risk  Elimination  by  PDR”  [Boehm  and  Royce  1989;  Figures  4  and  5]. 
Table  2-3  consolidates  the  concepts  to  form  a  comprehensive  definition  for  the  RESL  rating 
levels.  The  RESL  rating  is  the  subjective  weighted  average  of  the  listed  characteristics. 
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Table  2-3:  RESL  Rating  Components 


Characteristic 

Very  Low 

Low 

Nominal 

High 

Very 

High 

Extra 

High 

Risk  Management  Pian 
identifies  ali  critical  risk 
items,  establishes 
milestones  for  resolving 
them  by  PDR. 

None 

Little 

Some 

Generaily 

Mostly 

Fully 

Schedule,  budget,  and 
internal  milestones  through 
PDR  compatible  with  Risk 
Management  Plan 

None 

Little 

Some 

Generally 

Mostly 

Fully 

Percent  of  development 
schedule  devoted  to 
establishing  architecture, 
given  general  product 
objectives 

5 

10 

17 

25 

33 

40 

Percent  of  required  top 
software  architects 
available  to  project 

20 

40 

60 

80 

100 

120 

Tool  support  available  for 
resolving  risk  items, 
developing  and  verifying 
architectural  specs 

None 

Little 

Some 

Good 

Strong 

Full 

Level  of  uncertainty  in  Key 
architecture  drivers: 
mission,  user  interface, 
COTS,  hardware, 
technology,  performance. 

Extreme 

Signifi¬ 

cant 

Consider 

able 

Some 

Little 

Very 

Little 

Number  and  criticality  of 
risk  items 

>  10 
Critical 

5-10 

Critical 

2-4 

Critical 

1 

Critical 

>  5  Non- 
Critical 

<  5  Non- 
Critical 

2.3.3.3  Team  Cohesion  (TEAM) 

The  Team  Cohesion  scale  factor  accounts  for  the  sources  of  project  turbulence  and  entropy  due  to 
difficulties  in  synchronizing  the  project’s  stakeholders:  users,  customers,  developers,  maintainers, 
interfacers,  others.  These  difficulties  may  arise  from  differences  in  stakeholder  objectives  and 
cultures;  difficulties  in  reconciling  objectives;  and  stakeholder’s  lack  of  experience  and 
familiarity  in  operating  as  a  team.  Table  2-4  provides  a  detailed  definition  for  the  overall  TEAM 
rating  levels.  The  final  rating  is  the  subjective  weighted  average  of  the  listed  characteristics. 
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Table  2-4:  TEAM  Rating  Components 


Characteristic 

Very 

Low 

Low 

Nominal 

High 

Very  High 

Extra 

High 

Consistency  of  stakeholder 
obiectives  and  cultures 

Little 

Some 

Basic 

Consider¬ 

able 

Strong 

Full 

Ability,  willingness  of 
stakeholders  to 
accommodate  other 
stakeholders’  objectives 

Little 

Some 

Basic 

Consider¬ 

able 

Strong 

Full 

Experience  of  stakeholders 
in  operating  as  a  team 

None 

Little 

Little 

Basic 

Consider¬ 

able 

Extensive 

Stakeholder  teambuilding  to 
achieve  shared  vision  and 
commitments 

None 

Little 

Little 

Basic 

Consider¬ 

able 

Extensive 

2.3.3.4  Process  Maturity  (PMAT) 

The  procedure  for  determining  PMAT  is  organized  around  the  Software  Engineering  Institute’s 
Capability  Maturity  Model  (CMM).  The  time  period  for  rating  Process  Maturity  is  the  time  the 
project  starts.  There  are  two  ways  of  rating  Process  Maturity.  The  first  captures  the  result  of  an 
organization  evaluation  based  on  the  CMM  (an  Assessment  or  a  Capability  Evaluation). 

Overall  Maturity  Level 

CMM  Level  1  (lower  half) 

CMM  Level  1  (upper  half) 

CMM  Level  2 
CMM  Level  3 
CMM  Level  4 
CMM  Level  5 
Key  Process  Areas 

The  second  is  organized  around  the  18  Key  Process  Areas  (KPAs)  in  the  SEI  Capability  Maturity 
Model  [Paulk  et  al.  1993, 1993a].  The  procedure  for  determining  PMAT  is  to  decide  the 
percentage  of  compliance  for  each  of  the  KPAs.  If  the  project  has  undergone  a  recent  CMM 
Assessment  then  the  percentage  compliance  for  the  overall  KPA  (based  on  KPA  Key  Practice 
compliance  assessment  data)  is  used.  If  an  assessment  has  not  been  done  then  the  levels  of  com¬ 
pliance  to  the  KPA’s  goals  are  used  (with  the  Likert  scale  below)  to  set  the  level  of  compliance. 
The  goal-based  level  of  compliance  is  determined  by  a  judgement-based  averaging  across  the 
goals  for  each  Key  Process  Area. 
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Table  2-5 


Key  Process  Areas 

Almost 

Often 

About 

Occasion 

Rarely  If 

Does  Not 

Don’t 

Always 

(60-90%) 

Half 

-ally 

Ever 

Apply 

Know 

(>90%) 

(40-60%) 

(10-40%) 

(<10%) 

Requirements  Management 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

Software  Project  Planning 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

Software  Project  Tracking  and  Oversight 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

Software  Subcontract  Management 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

Software  Quality  Assurance 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

Software  Configuration  Management 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

Organization  Process  Focus 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

Organization  Process  Definition 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

Training  Program 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

Integrated  Software  Management 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

Software  Product  Engineering 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

Intergroup  Coordination 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

Peer  Reviews 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

Quantitative  Process  Management 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

Software  Quality  Management 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

Defect  Prevention 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

Technology  Change  Management 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

Process  Change  Management 

□ 

□ 

□ 

□ 

□ 

□ 

□ 

•  Check  Almost  Always  when  the  goals  are  consistently  achieved  and  are  well-established  in 
standard  operating  procedures  (over  90%  of  the  time). 

•  Check  Frequently  when  the  goals  are  achieved  relatively  often,  but  sometimes  are  omitted 
under  difficult  circumstances  (about  60  to  90%  of  the  time). 

•  Check  About  Half  when  the  goals  are  achieved  about  half  of  the  time  (about  40  to  60%  of  the 
time). 

•  Check  Occasionally  when  the  goals  are  sometimes  achieved,  but  less  often  (about  1 0  to  40% 
of  the  time). 

•  Check  Rarely  If  Ever  when  the  goals  are  rarely  if  ever  achieved  (less  than  10%  of  the  time). 

•  Check  Does  Not  Apply  when  you  have  the  required  knowledge  about  your  project  or  orga¬ 
nization  and  the  KPA,  but  you  feel  the  KPA  does  not  apply  to  your  circumstances. 

•  Check  Don’t  Know  when  you  are  uncertain  about  how  to  respond  for  the  KPA. 

After  the  level  of  KPA  compliance  is  determined  each  compliance  level  is  weighted  and  a  PMAT 

factor  is  calculated,  as  in  Equation  2.3.  Initially,  all  KPAs  will  be  equally  weighted. 


'  18 

fKPA%,  ^  5  )] 

_/=l 

o 

o 

00 

(2.3) 
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2.4  Adjusting  Nominal  Effort 

Cost  drivers  are  used  to  capture  characteristics  of  the  software  development  that  affect  the  effort 
to  complete  the  project.  Cost  drivers  that  have  a  multiplicative  effect  on  predicting  effort  are 
called  Effort  Multipliers  (EM).  Each  EM  has  a  rating  level  that  expresses  the  impact  of  the 
multiplier  on  development  effort,  PM.  These  rating  can  range  from  Extra  Low  to  Extra  High.  For 
the  purposes  of  quantitative  analysis,  each  rating  level  of  each  EM  has  a  weight  associated  with 
it.  The  nominal  or  average  weight  for  an  EM  is  1.0.  If  a  rating  level  causes  more  software 
development  effort,  then  its  corresponding  EM  weight  is  above  1.0.  Conversely,  if  the  rating 
level  reduces  the  effort  then  the  corresponding  EM  weight  is  less  than  1 .0.  The  selection  of 
effort-multipliers  is  based  on  a  strong  rationale  that  they  would  independently  explain  a  signifi¬ 
cant  source  of  project  effort  or  productivity  variation. 

2.4.1  Early  Design  Model 

The  Early  Design  model  is  used  in  the  early  stages  of  a  software  project  when  very  little  may  be 
known  about  the  size  of  the  product  to  be  developed,  the  nature  of  the  target  platform,  the  nature 
of  the  personnel  to  be  involved  in  the  project,  or  the  detailed  specifics  of  the  process  to  be  used. 
This  model  could  be  employed  in  Application  Generator,  System  Integration,  or  Infrastructure 
development  sectors. 

The  Early  Design  model  adjusts  the  nominal  effort  using  7  EMs,  Equation  2.4.  Each  multiplier 
has  7  possible  weights.  The  cost  drivers  for  this  model  are  explained  in  the  next  chapter. 


=  PM 

nominal  ^ 


(2.4) 


2.4.2  Post-Architecture  Model 

The  Post-Architecture  model  is  the  most  detailed  estimation  model  and  it  is  intended  to  be  used 
when  a  software  life-cycle  architecture  has  been  developed.  This  model  is  used  in  the 
development  and  maintenance  of  software  products  in  the  Application  Generators,  System  Inte¬ 
gration,  or  Infrastructure  sectors,  see  Chapter  1. 

The  Post- Architecture  model  adjusts  nominal  effort  using  17  effort  multipliers.  The  larger 
number  of  multipliers  takes  advantage  of  the  greater  knowledge  available  later  in  the  develop¬ 
ment  stage.  The  Post-Architecture  effort  multipliers  are  explained  in  the  next  chapter 


adjusted  no  min  al  ^ 


(2.5) 


2.5  Development  Schedule  Estimation 

COCOMO II  provides  a  simple  schedule  estimation  capability.  The  baseline  schedule  equation 
for  all  three  COCOMO  II  stages  is: 


TDEV  =  [3.67  X  ”» ]x 


(2.6) 


Where  TDEV  is  the  calendar  time  in  months  from  the  determination  of  a  product’s  requirements 
baseline  to  the  completion  of  an  acceptance  activity  certifying  that  the  product  satisfies  its 
requirements.  PM  is  the  estimated  person-months  excluding  the  SCED  effort  multiplier,  B  is  the 
sum  of  project  scale  factors  (discussed  in  the  next  chapter)  and  SCED%  is  the  compression  / 
expansion  percentage  in  the  SCED  effort  multiplier  in  Table  3-14  and  Appendix  3. 


3  COCOMO  II  Model  Detail 

3.1  Determining  Size 

3.1.1  Lines  of  Code 

In  COCOMO  II,  the  logical  source  statement  has  been  chosen  as  the  standard  line  of  code. 
Defining  a  line  of  code  is  difficult  due  to  conceptual  differences  involved  in  accounting  for  exe¬ 
cutable  statements  and  data  declarations  in  different  languages.  The  goal  is  to  measure  the 
amount  of  intellectual  work  put  into  program  development,  but  difficulties  arise  when  trying  to 
define  consistent  measures  across  different  languages.  Table  3.1  shows  a  portion  of  the  Software 
Engineering  Institute’s  (SEI)  definition  checklist  as  it  is  being  applied  to  support  the  development 
of  the  COCOMO  II  model.  Detailed  information  and  the  complete  checklist  are  available  [Model 
Manual]. 
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Table  3.1  Definition  Checklist  for  Source  Statements  Counts 

Definition  name: _ Logical  Source  Statements _ Date: - 

_ (basic  definition')  Originator:  COCOMOII - 


Measurement  unit:  Physical  source  lines 

Logicai  source  statements 

t\/nei  Definition  1  1  Data  Array 

Includes 

Excludes 

When  a  line  or  statement  contains  more  than  one  type, 
classify  it  as  the  type  with  the  highest  precedence. 

1  Executable  Order  of  precedence 

2  Nonexecutable 

3  Declarations 

4  Compiler  directives 

5  Comments 

6  On  their  own  lines 

7  On  lines  with  source  code 

8  Banners  and  non-blank  spacers 

9  Blank  (empty)  comments 

10  Blank  lines 

11 

12 

1 

✓ 

2 

/ 

3 

y 

4 

y 

5 

y 

6 

y 

7 

y 

8 

y 

How  produced  Definition 

✓  1  Data  array  I 

Includes 

Excludes 

y 

1  riuyidiiiiMcu 

2  Generated  with  source  code  generators 

3  Converted  with  automated  translators 

4  Copied  or  reused  without  change 

5  Modified 

6  Removed 

7 

8 

/ 

y 

y 

y 

/ 

Origin  Definition 

•/  Data  array  |  I 

Includes 

Excludes 

✓ 

2  Prior  work:  taken  or  adapted  from 

3  A  previous  version,  build,  or  release 

4  Commercial,  off-the-shelf  software  (COTS),  other  than  libraries 

5  Government  furnished  software  (GFS),  other  than  reuse  libraries 

6  Another  product 

7  A  vendor-supplied  language  support  library  (unmodified) 

8  A  vendor-supplied  operating  system  or  utility  (unmodified) 

9  A  local  or  modified  language  support  library  or  operating  system 

10  Other  commercial  library 

1 1  A  reuse  library  (software  designed  for  reuse) 

12  Other  software  component  or  library 

13 

14  _ _ _ _ 

/ 

y 

y 

y 

y 

y 

y 

y 

/ 

y 

3.1.2  Function  Points 

The  function  point  cost  estimation  approach  is  based  on  the  amount  of  functionality  in  a  software 
project  and  a  set  of  individual  project  factors.  Function  points  measure  a  software  project  by 
quantifying  the  information  processing  functionality  associated  with  major  external  data  or 
control  input,  output,  or  file. 
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3.2  Breakage 


COCOMO II  uses  a  breakage  percentage,  BRAK,  to  adjust  the  effective  size  of  the  product. 
Breakage  reflects  the  requirements  volatility  in  a  project.  It  is  the  percentage  of  code  thrown 
away  due  to  requirements  changes.  For  example,  a  project  which  delivers  100,000  instructions 
but  discards  the  equivalent  of  an  additional  20,000  instructions  has  a  BRAK  value  of  20.  This 
would  be  used  to  adjust  the  project’s  effective  size  to  120,000  instructions  for  a  COCOMO  II 
estimation 

3.3  Adjusting  for  Reuse 

COCOMO  adjusts  for  the  reuse  by  modifying  the  size  of  the  module  or  project.  The  model  treats 
reuse  with  function  points  and  source  lines  of  code  the  same  in  either  the  Early  Design  model  or 
the  Post-Architecture  model. 

3.3.1  Nonlinear  Reuse  Effects 

Analysis  of  reuse  costs  indicates  that  the  reuse  cost  function  is  nonlinear  in  two  significant  ways 
(see  Figure  3-1): 

•  It  does  not  go  through  the  origin.  There  is  generally  a  cost  of  about  5%  for  assessing, 
selecting,  and  assimilating  the  reusable  component. 

•  Small  modifications  generate  disproportionately  large  costs.  This  is  primarily  due  to  two 
factors:  the  cost  of  understanding  the  software  to  be  modified,  and  the  relative  cost  of 
interface  checking. 


D on  2954 


Amount  M  odified 

Figure  3-1:  Nonlinear  Reuse  Effects 


3.3.2  A  Reuse  Model 

The  COCOMO  II  treatment  of  software  reuse  uses  a  nonlinear  estimation  model.  Equation  3.1. 
This  involves  estimating  the  amount  of  software  to  be  adapted,  ASLOC,  and  three  degree-  of- 
modification  parameters:  the  percentage  of  design  modified  (DM),  the  percentage  of  code 
modified  (CM),  and  the  percentage  of  modification  to  the  original  integration  effort  required  for 
integrating  the  reused  software  (IM). 


12 


The  Software  Understanding  increment  (SU)  is  obtained  from  Table  3-2.  SU  is  expressed 
quantitatively  as  a  percentage.  If  the  software  is  rated  very  high  on  structure,  applications  clarity, 
and  self-descriptiveness,  the  software  understanding  and  interface  checking  penalty  is  10%.  If  the 
software  is  rated  very  low  on  these  factors,  the  penalty  is  50%.  SU  is  determined  by  taking  the 
subjective  average  of  the  three  categories. 

Table  3-2:  Rating  Scale  for  Software  Understanding  Increment  SU 


Very  Low 

Low 

Norn 

High 

Very  High 

Structure 

Very  low 
cohesion,  high 
coupling,  spa¬ 
ghetti  code. 

Moderately  low 
cohesion,  high 
coupling. 

Reasonably 
well  structured; 
some  weak 

areas. 

High  cohesion, 
low  coupling. 

Strong  modular¬ 
ity,  information 
hiding  in  data  / 
control 
structures. 

Application 

Clarity 

No  match 
between  program 
and  application 
world  views. 

Some 
correlation 
between 
program  and 
application. 

Moderate 
correlation 
between  pro¬ 
gram  and 
application. 

Good 
correlation 
between 
program  and 
application. 

Clear  match 
between 
program  and 
application 
world-views. 

Self- 

Descriptiveness 

Obscure  code; 
documentation 
missing,  obscure 
or  obsolete 

Some  code 
commentary 
and  headers; 
some  useful 
documentation. 

Moderate  level 
of  code 
commentary, 
headers,  docu¬ 
mentations. 

Good  code 
commentary 
and  headers; 
useful 

documentation; 
some  weak 

areas. 

Self-descriptive 

code; 

documentation 
up-to-date,  well 
organized,  with 
design  ratio¬ 
nale. 

SU  Increment  to 
ESLOC 

50 

40 

30 

20 

10 

The  other  nonlinear  reuse  increment  deals  with  the  degree  of  Assessment  and  Assimilation  (AA) 
needed  to  determine  whether  a  fully  reused  software  module  is  appropriate  to  the  application,  and 
to  integrate  its  description  into  the  overall  product  description.  Table  3-3  provides  the  rating  scale 
and  values  for  the  assessment  and  assimilation  increment.  AA  is  a  percentage. 

Table  3-3:  Rating  Scale  for  Assessment  and  Assimilation  Increment  (AA) 


AA  Increment 

Level  of  AA  Effort 

0 

None 

2 

Basic  module  search  and  documentation 

4 

Some  module  Test  and  Evaluation  (T&E),  documentation 

6 

Considerable  module  T&E,  documentation 

8 

Extensive  module  T&E,  documentation 

The  amount  of  effort  required  to  modify  existing  software  is  a  function  not  only  of  the  amount  of 
modification  (AAF)  and  understandability  of  the  existing  software  (SU),  but  also  of  the 
programmer’s  relative  unfamiliarity  with  the  software  (UNFM).  The  UNFM  parameter  is  applied 
multiplicatively  to  the  software  understanding  effort  increment.  If  the  programmer  works  with  the 
software  every  day,  the  0.0  multiplier  for  UNFM  will  add  no  software  understanding  increment. 


If  the  programmer  has  never  seen  the  software  before,  the  1 .0  multiplier  will  add  the  full  software 
understanding  effort  increment.  The  rating  of  UNFM  is  in  Table  3-4. 

Table  3-4:  Rating  Scale  for  Programmer  Unfamiliarity  (UNFM) 


UNFM  Increment 

Level  of  Unfamiliarity 

0.0 

Completely  familiar 

0.2 

Mostly  familiar 

0.4 

Considerably  familiar 

0.6 

Somew/hat  familiar 

0.8 

Mostly  unfamiliar 

1.0 

Completely  unfamiliar 

AAF  =  0.4(£)A/)  +  0.3(CA/)  +  0.3(/M) 

ESLOC  ^  ^ 

100 

ASLOC[AA  +  AAF  +  {,SU){UNFM)]  _ 

ESLOC  = - ,AAF  >  0.5 

100 

Equation  3.1  is  used  to  determine  an  equivalent  number  of  new  instructions,  equivalent  source 
lines  of  code  (ESLOC).  ESLOC  is  divided  by  one  thousand  to  derive  KESLOC  which  is  used  as 
the  COCOMO  size  parameter.  The  calculation  of  ESLOC  is  based  on  an  intermediate  quantity, 
the  Adaptation  Adjustment  Factor  (AAF).  The  adaptation  quantities,  DM,  CM,  IM  are  used  to 
calculate  AAF  where: 

•  DM:  Percent  Design  Modified.  The  percentage  of  the  adapted  software’s  design  which  is 
modified  in  order  to  adapt  it  to  the  new  objectives  and  environment.  (This  is  necessarily  a 
subjective  quantity.) 

•  CM:  Percent  Code  Modified.  The  percentage  of  the  adapted  software’s  code  which  is 
modified  in  order  to  adapt  it  to  the  new  objectives  and  environment. 

•  IM:  Percent  of  Integration  Required  for  Modified  Software.  The  percentage  of  effort  required 
to  integrate  the  adapted  software  into  an  overall  product  and  to  test  the  resulting  product  as 
compared  to  the  normal  amount  of  integration  and  test  effort  for  software  of  comparable  size. 

If  there  is  no  DM  or  CM  (the  component  is  being  used  unmodified)  then  there  is  no  need  for  SU. 
If  the  code  is  being  modified  then  SU  applies. 

3.4  Adjusting  for  Re-engineering  or  Conversion 

The  COCOMO  II  reuse  model  needs  additional  refinement  to  estimate  the  costs  of  software  re¬ 
engineering  and  conversion.  The  major  difference  in  re-engineering  and  conversion  is  the 
efficiency  of  automated  tools  for  software  restructuring.  Equation  3.2  shows  how  automated 
translation  affects  the  estimated  nominal  effort,  PM. 


PM„o„M=Ax{SizeY  F 


ASLOC 


AT 

100 


ATPROD 


(3.2) 
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3.5  Applications  Maintenance 


COCOMO II  uses  the  reuse  model  for  maintenance  when  the  amount  of  added  or  changed  base 
source  code  is  less  than  or  equal  to  20%  of  the  new  code  being  developed.  Base  code  is  source 
code  that  already  exists  and  is  being  changed  for  use  in  the  current  project.  For  maintenance 
projects  that  involve  more  than  20%  change  in  the  existing  base  code  (relative  to  new  code  being 
developed)  COCOMO  II  uses  maintenance  size.  An  initial  maintenance  size  is  obtained  in  one  of 
two  ways,  Equation  3.3  or  Equation  3.5.  Equation  3.3  is  used  when  the  base  code  size  is  known 
and  the  percentage  of  change  to  the  base  code  is  known. 

{SIZE)m  =  ^Base  Code  Size)  •  MCF]  ■  MAF  (3 .3) 

The  percentage  of  change  to  the  base  code  is  called  the  Maintenance  Change  Factor  (MCF).  The 
MCF  is  for  maintenance  periods  other  than  a  year.  Conceptually  the  MCF  represents  the  ratio  in 
Equation  3.4: 

ji^CF  -  +  Size  Modified  ^2  4) 

Base  Code  Size 


Equation  3.5  is  used  when  the  fraction  of  code  added  or  modified  to  the  existing  base  code  during 
the  maintenance  period  is  known.  Deleted  code  is  not  counted. 

{Size) M  {Size  Added  +  Size  Modified) -MAF  (3.5) 

The  size  can  refer  to  thousands  of  source  lines  of  code  (KSLOC),  Function  Points,  or  Object 
Points.  When  using  Function  Points  or  Object  Points,  it  is  better  to  estimate  MCF  in  terms  of  the 
fraction  of  the  overall  application  being  changed,  rather  than  the  fraction  of  inputs,  outputs, 
screens,  reports,  etc.  touched  by  the  changes.  Our  experience  indicates  that  counting  the  items 
touched  can  lead  to  significant  over  estimates,  as  relatively  small  changes  can  touch  a  relatively 
large  number  of  items. 

The  initial  maintenance  size  estimate  (described  above)  is  adjusted  with  a  Maintenance 
Adjustment  Factor  (MAF),  Equation  3.6.  COCOMO  II  uses  the  Software  Understanding  (SU) 
and  Programmer  Unfamiliarity  (UNFM)  factors  from  its  reuse  model  to  model  the  effects  of  well 
or  poorly  structured/understandable  software  on  maintenance  effort. 


MAF  =  \  + 


'SU 

,100 


■UNFM 


{2.6) 


The  resulting  maintenance  effort  estimation  formula  is  the  same  as  the  COCOMO  II  Post- 
Architecture  development  model: 


PMu=A- (SIZE^  f  ■  n EM,  (3.7) 

/=1 

The  COCOMO  II  approach  to  estimating  either  the  maintenance  activity  duration,  T^,  or  the 
average  maintenance  staffing  level,  FSPjj/,  is  via  the  relationship: 
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(3.8) 


PM^=T^-FSP^ 

Most  maintenance  is  done  as  a  level  of  effort  activity.  This  relationship  can  estimate  the  level  of 
effort,  FSP^,  given  T^(as  in  annual  maintenance  estimates,  where  TjVf  =  12  months),  or  vice- 
versa  (given  a  fixed  maintenance  staff  level,  FSPjj/,  determine  the  necessary  time,  Tji/,  to 
complete  the  effort). 

3.6  Effort  Multipliers 

The  application  of  project  scale  factors  is  the  same  for  Early  Design  and  the  Post-Architecture 
models  and  was  described  in  section  2.3.  In  the  Early  Design  model  a  reduced  set  of  the  Post 
Architecture  cost  drivers  are  used. 

3.6.1  Early  Design 

Appendix  2  contains  the  numeric  values  for  the  COCOMO  II — 1998  Effort  Multiplers.  The  rest 
of  this  section  discusses  the  scale  factors  in  terms  of  their  nominal  levels. 

The  Early  Design  model  uses  KSLOC  for  size.  Unadjusted  function  points  are  converted  to  the 
equivalent  SLOG  and  then  to  KSLOC.  The  Early  Design  cost  drivers  are  obtained  by  combining 
the  Post- Architecture  model  cost  drivers  from  Table  3-14.  Whenever  an  assessment  of  a  cost 
driver  is  between  the  rating  levels  always  round  to  the  Nominal  rating,  e.g.  if  a  cost  driver  rating 
is  between  Very  Low  and  Low,  then  select  Low. 

Table  3-5:  Early  Design  and  Post- Architecture  Effort  Multipliers 


Early  Design  Cost  Driver 

Counterpart  Combined 
Post-Architecture  Cost  Drivers 

RCPX 

RELY,  DATA,  CPLX,  DOCU 

RUSE 

RUSE 

PDIF 

TIME,  STOR,  PVOL 

PERS 

ACAP,  PCAP,  PCON 

PREX 

AEXP,  PEXP,  LTEX 

FOIL 

TOOL,  SITE 

SCED 

SCED 

Overall  Approach:  Personnel  Capability  (PERS)  Example 

The  following  approach  is  used  for  mapping  the  full  set  of  Post- Architecture  cost  drivers  and 
rating  scales  onto  their  Early  Design  model  counterparts.  It  involves  the  use  and  combination  of 
numerical  equivalents  of  the  rating  levels.  Specifically,  a  Very  Low  Post-Architecture  cost  driver 
rating  corresponds  to  a  numerical  rating  of  1,  Low  is  2,  Nominal  is  3,  High  is  4,  Very  High  is  5, 
and  Extra  High  is  6.  For  the  combined  Early  Design  cost  drivers,  the  numerical  values  of  the 
contributing  Post-Architecture  cost  drivers.  Table  3-5,  are  summed,  and  the  resulting  totals  are 
allocated  to  an  expanded  Early  Design  model  rating  scale  going  from  Extra  Low  to  Extra  High. 
The  Early  Design  model  rating  scales  always  have  a  Nominal  total  equal  to  the  sum  of  the 
Nominal  ratings  of  its  contributing  Post-Architecture  elements. 
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Table  3-6:  PERS  Rating  Levels 


Extra 

Low 

Very 

Low 

Low 

Nominal 

High 

Very 

High 

Extra 

High 

Sum  of  ACAP, 

PCAP,  PCON 

Ratings 

3,4 

5,6 

7,8 

9 

10,  11 

12, 13 

14, 15 

Combined  ACAP 
and  PCAP 

Percentile 

20% 

39% 

45% 

55% 

65% 

75% 

85% 

Annual  Personnel 
Turnover 

45% 

30% 

20% 

12% 

9% 

5% 

4% 

The  rating  scales  and  effort  multipliers  for  PERS  and  the  other  Early  Design  cost  drivers  maintain 
consistent  relationships  with  their  Post-Architecture  counterparts.  For  example,  the  PERS  Extra 
Low  rating  levels  (20%  combined  ACAP  and  PCAP  percentile;  45%  personnel  turnover) 
represent  averages  of  the  ACAP,  PCAP,  and  PCON  rating  levels  adding  up  to  3  or  4. 

Maintaining  these  consistency  relationships  between  the  Early  Design  and  Post- Architecture 
rating  levels  ensures  consistency  of  Early  Design  and  Post- Architecture  cost  estimates.  It  also 
enables  the  rating  scales  for  the  individual  Post- Architecture  cost  drivers.  Table  3-14,  to  be  used 
as  detailed  backups  for  the  top-level  Early  Design  rating  scales  given  below. 

Product  Reliability  and  Complexity  (RCPX) 

This  Early  Design  cost  driver  combines  the  four  Post-Architecture  cost  drivers  Required 
Software  Reliability  (RELY),  Data  size  (DATA),  Product  complexity  (CPLX),  and 
Documentation  match  to  life  cycle  needs  (DOCU).  Unlike  the  PERS  components,  the  RCPX 
components  have  rating  scales  with  differing  width.  RELY  and  DOCU  range  from  Very  Low  to 
Very  High;  DATA  ranges  from  Low  to  Very  High,  and  CPLX  ranges  from  Very  Low  to  Extra 
High.  The  numerical  sum  of  their  ratings  thus  ranges  from  5  (VL,  L,  VL,  VL)  to  21  (VH,  VH, 

EH,  VH). 

Table  3-7  assigns  RCPX  ratings  across  this  range,  and  associates  appropriate  rating  scales  to  each 
of  the  RCPX  ratings  from  Extra  Low  to  Extra  High.  As  with  PERS,  the  Post-  Architecture  RELY, 
DATA,  CPLX,  and  DOCU  rating  scales  in  Table  3-14  provide  detailed  backup  for  interpreting 
the  Early  Design  RCPX  rating  levels. 
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Table  3-7:  RCPX  Rating  Levels 


Extra 

Low 

Very 

Low 

Low 

Nomina 

I 

High 

Very 

High 

Extra 

High 

Sum  of  RELY.  DATA. 
CPLX.  DOCU  Ratings 

5.6 

7.8 

9-11 

12 

13-15 

16-18 

19-21 

Emphasis  on  reliability, 
documentation 

Very 

little 

Little 

Some 

Basic 

Strong 

Very 

Strong 

Extreme 

Product  complexity 

Very 

simple 

Simple 

Some 

Moder¬ 

ate 

Comple 

X 

Extremel 

y 

complex 

Data  size 

Small 

Small 

Small 

Moder¬ 

ate 

Large 

Very 

Large 

Very 

Large 

Required  Reuse  (RUSE) 

This  Early  Design  model  cost  driver  is  the  same  as  its  Post-  Architecture  counterpart,  v^^hich  is 
covered  in  the  section  on  the  Post- Architecture  model.  A  summary  of  its  rating  levels  is  given 
below  and  in  Table  3-14. 

Table  3-8:  RUSE  Rating  Level  Summary 


Very  Low 

Low 

Nominal 

mmn 

Very  High 

Extra 

High 

RUSE 

none 

across 

project 

across  pro¬ 
gram 

across 
product  line 

across 

multiple 

product 

lines 

Platform  Difficulty  (PDIF) 

This  Early  Design  cost  driver  combines  the  three  Post-  Architecture  cost  drivers  execution  time 
(TIME),  main  storage  constraint  (STOR),  and  platform  volatility  (PVOL).  TIME  and  STOR 
range  from  Nominal  to  Extra  High;  PVOL  ranges  from  Low  to  Very  High.  The  numerical  sum  of 
their  ratings  thus  ranges  from  8  (N,  N,  L)  to  17  (EH,  EH,  VH). 

Table  3-9  assigns  PDIF  ratings  across  this  range,  and  associates  the  appropriate  rating  scales  to 
each  of  the  PDIF  rating  levels.  The  Post-Architecture  rating  scales  in  Table  3-14  provide 
additional  backup  definition  for  the  PDIF  ratings  levels. 
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Table  3-9:  PDIF  Rating  Levels 


Low 

Nominal 

High 

Very  High 

Extra 

High 

Sum  of  TIME,  STOR,  and 
PVOL  ratings 

8 

9 

10-12 

13-15 

16,  17 

Time  and  storage  constraint 

50% 

50% 

65% 

80% 

90% 

Platform  volatility 

Very  stable 

Stable 

Somewhat 

volatile 

Volatile 

Highly 

volatile 

Personnel  Experience  (PREX) 

This  Early  Design  cost  driver  combines  the  three  Post- Architecture  cost  drivers  application 
experience  (AEXP),  platform  experience  (PEXP),  and  language  and  tool  experience  (LTEX). 
Each  of  these  range  from  Very  Low  to  Very  High;  as  with  PERS,  the  numerical  sum  of  their 
ratings  ranges  from  3  to  15. 

Table  3-10  assigns  PREX  ratings  across  this  range,  and  associates  appropriate  effort  multipliers 
and  rating  scales  to  each  of  the  rating  levels. 

Table  3-10:  PREX  Rating  Levels 


Extra 

Low 

Very 

Low 

Low 

Nominal 

High 

Very 

High 

Extra 

High 

Sum  of  AEXP,  PEXP, 
and  LTEX  ratings 

wm 

5,6 

7.8 

9 

10,  11 

12, 13 

14,  15 

Applications,  Platform, 
Language  and  Tool 
Experience 

~  3  mo. 

5 

months 

9 

months 

1  year 

2 

years 

4  years 

6 

years 

Facilities  (FOIL) 

This  Early  Design  cost  driver  combines  the  two  Post-Architecture  cost  drivers:  use  of  software 
tools  (TOOL)  and  multisite  development  (SITE).  TOOL  ranges  from  Very  Low  to  Very  High; 
SITE  ranges  from  Very  Low  to  Extra  High.  Thus,  the  numerical  sum  of  their  ratings  ranges  from 
2  (VL,  VL)  to  1 1  (VH,  EH). 

Table  3-1 1  assigns  FOIL  ratings  across  this  range,  and  associates  appropriate  rating  scales  to  each 
of  the  FOIL  rating  levels.  The  individual  Post- Architecture  TOOL  and  SITE  rating  scales  in 
Table  3-1 1  again  provide  additional  backup  definition  for  the  FOIL  rating  levels. 
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Table  3-11:  FCIL  Rating  Levels 


Extra 

Low 

Very  Low 

Low 

Nominal 

High 

Very 

High 

Extra  High 

Sum  of  TOOL 
and 

SITE  ratings 

2 

3 

■ 

6 

7,8 

9.  10 

11 

TOOL  support 

Minimal 

Some 

Simple 

CASE 

tool 

collectio 

n 

Basic 

life- 

cycle 

tools 

Good; 

moder¬ 

ately 

inte¬ 

grated 

Strong; 

moder¬ 

ately 

inte¬ 

grated 

Strong; 

well 

integrated 

Multisite 

conditions 

Weak 

support 

of 

complex 

multisite 

develop¬ 

ment 

Some 

support 

of 

complex 

M/S 

devel. 

Some 

support 

of 

moder¬ 

ately 

complex 

M/S 

devel. 

Basic 

support 

of 

moder¬ 

ately 

complex 

M/S 

devel. 

Strong 

support 

of 

moder¬ 

ately 

complex 

M/S 

devel. 

Strong 
support 
of  simple 
M/S 
devel. 

Very 
strong 
support  of 
collocated 
or  simple 
M/S  devel. 

Schedule  (SCED) 

The  Early  Design  cost  driver  is  the  same  as  its  Post-Architecture  counterpart.  A  summary  of  its 
rating  levels  is  given  in  Table  3-12  below. 

Table  3-12:  SCED  Rating  Level  Summary 


Very  Low 

Low 

Nominal 

High 

Very  High 

Extra 

High 

SCED 

75%  of 
nominal 

85% 

100% 

130% 

160% 

3.6.2  Post-Architecture 

Appendix  3  contains  the  numeric  values  for  the  COCOMO II — 1998  Effort  Multiplers.  The  rest 
of  the  sections  discusses  the  scale  factors  in  terms  of  their  nominal  levels. 

These  are  the  17  effort  multipliers  used  in  COCOMO  II  Post- Architecture  model  to  adjust  the 
nominal  effort,  Person  Months,  to  reflect  the  software  product  under  development.  They  are 
grouped  into  four  categories:  product,  platform,  personnel,  and  project.  Figure  3-18  lists  the  dif¬ 
ferent  cost  drivers  with  their  rating  criterion  (found  at  the  end  of  this  section).  Whenever  an 
assessment  of  a  cost  driver  is  between  the  rating  levels  always  round  to  the  Nominal  rating,  e.g.  if 
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a  cost  driver  rating  is  between  High  and  Very  High,  then  select  High.  The  counterpart  7  effort 
multipliers  for  the  Early  Design  model  are  discussed  in  the  chapter  explaining  that  model 

3.6.2.1  Product  Factors 

Required  Software  Reliability  (RELY) 


This  is  the  measure  of  the  extent  to  which  the  software  must  perform  its  intended  function  over  a 
period  of  time.  If  the  effect  of  a  software  failure  is  only  slight  inconvenience  then  RELY  is  low. 
If  a  failure  would  risk  human  life  then  RELY  is  very  high. 


Very  Low 

Low 

Nominal 

High 

Very  High 

Extra 

High 

RELY 

slight 

inconvenie 

nee 

low,  easily 
recoverabi 
e  losses 

moderate, 
easily 
recoverabi 
e  losses 

high 

financial 

loss 

risk  to 
human  life 

Data  Size  (DATA) 

This  measure  attempts  to  capture  the  affect  large  data  requirements  have  on  product 
development.  The  rating  is  determined  by  calculating  D/P.  The  reason  the  amount  of  data  is 
important  to  consider  it  because  of  the  effort  required  to  generate  the  test  data  that  will  be  used  to 
exercise  the  program. 

D  _  Data  Size  (Bytes)  Eq  | 

P  Program  Size  (SLOC) 

DATA  is  rated  as  low  if  D/P  is  less  than  10  and  it  is  very  high  if  it  is  greater  than  1000. 


Very  Low 

Low 

Nominal 

High 

Very  High 

Extra 

High 

DATA 

D  bytes/ 
Pgm  SLOC 
<  10 

10  D/P< 
100 

100  D/P< 
1000 

D/P>  1000 

Product  Complexity  (CPLX) 

Table  3-13  (found  at  the  end  of  this  section)  provides  the  CPLX  rating  scale.  Complexity  is 
divided  into  five  areas:  control  operations,  computational  operations,  device-dependent 
operations,  data  management  operations,  and  user  interface  management  operations.  Select  the 
area  or  combination  of  areas  that  characterize  the  product  or  a  sub-system  of  the  product.  The 
complexity  rating  is  the  subjective  weighted  average  of  these  areas. 
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Extra  High  Very  High  High  Nominal  Low  Very  Low 


Table  3-13:  Module  Complexity  Ratings  versus  Type  of  Module 


Control  Operations 

Computational 

Operations 

Device¬ 

dependent 

Operations 

Data 

Management 

Operations 

User  Interface 
Management 
Operations 

Straight-line  code  with  a 
few  non-nested  struc¬ 
tured  programming 
operators:  DOs, 

CASES,  IFTHENELSEs. 
Simple  module 
composition  via 
procedure  calls  or 
simple  scripts. 

Evaluation  of 
simple  expres¬ 
sions;  e.g., 
A=B+C*(D-E) 

Simple  read,  write 
statements  with 
simple  formats. 

Simple  arrays  in 
main  memory. 
Simple  COTS-DB 
queries,  updates. 

Simple  input 
forms,  report 
generators. 

Straightforward  nesting 
of  structured  pro¬ 
gramming  operators. 
Mostly  simple  predi¬ 
cates 

Evaluation  of 
moderate-level 
expressions:  e.g., 
D=SQRT(B**2- 
4.*A*C) 

No  cognizance 
needed  of  particu¬ 
lar  processor  or  1/ 
0  device  charac¬ 
teristics.  I/O  done 
at  GET/PUT  level. 

Single  file  subset¬ 
ting  with  no  data 
structure 

changes,  no  edits, 
no  intermediate 
files.  Moderately 
complex  COTS- 
DB  queries, 
updates. 

Use  of  simple 
graphic  user 
interface 
(GUI)  builders. 

Mostly  simple  nesting. 

Some  intermodule  con¬ 

trol.  Decision  tables. 
Simple  callbacks  or 
message  passing, 
including  middleware- 
supported  distributed 
processing 

Use  of  standard 
math  and  statisti¬ 
cal  routines.  Basic 
matrix/vector 
operations. 

I/O  processing 
includes  device 
selection,  status 
checking  and 
error  processing. 

Multi-file  input 
and  single  file 
output.  Simple 
structural 
changes,  simple 
edits.  Complex 
COTS-DB  que¬ 
ries,  updates. 

Simple  use  of 
widget  set. 

Highly  nested  struc¬ 
tured  programming 
operators  with  many 
compound  predicates. 
Queue  and  stack  con¬ 
trol.  Homogeneous,  dis¬ 
tributed  processing. 
Single  processor  soft 
real-time  control. 

Basic  numerical 
analysis:  multi¬ 
variate  interpola¬ 
tion,  ordinary 
differential  equa¬ 
tions.  Basic  trun¬ 
cation,  roundoff 
concerns. 

Operations  at 
physical  I/O  level 
(physical  storage 
address  transla¬ 
tions:  seeks, 
reads,  etc.).  Opti¬ 
mized  I/O  over¬ 
lap. 

Simple  triggers 
activated  by  data 
stream  contents. 
Complex  data 
restructuring. 

Widget  set 
development 
and  extension. 
Simple  voice 
I/O, 

multimedia. 

Reentrant  and  recursive 
coding.  Fixed-priority 
interrupt  handling.  Task 
synchronization, 
complex  callbacks,  het¬ 
erogeneous  distributed 
processing.  Single-pro¬ 
cessor  hard  real-time 
control. 

Difficult  but 
structured  numer¬ 
ical  analysis: 
near-singular 
matrix  equations, 
partial  differential 
equations.  Simple 
parallelization. 

Routines  for  inter¬ 
rupt  diagnosis, 
servicing,  mask¬ 
ing.  Communica¬ 
tion  line  handling. 
Performance- 
intensive  embed¬ 
ded  systems. 

Distributed  data¬ 
base  coordina¬ 
tion.  Complex 
triggers.  Search 
optimization. 

Moderately 
complex  2DI 
3D,  dynamic 
graphics, 
multimedia. 

Multiple  resource 
scheduling  with  dynam¬ 
ically  changing  priori¬ 
ties.  Microcode-level 
control.  Distributed  hard 
real-time  control. 

Difficult  and 
unstructured 
numerical  analy¬ 
sis:  highly  accu¬ 
rate  analysis  of 
noisy,  stochastic 
data.  Complex 
parallelization. 

Device  timing- 
dependent  cod¬ 
ing,  micro-pro¬ 
grammed 
operations.  Per¬ 
formance-critical 
embedded  sys¬ 
tems. 

Highly  coupled, 
dynamic  relational 
and  object 
structures. 

Natural  language 
data 

management. 

Complex  mul¬ 
timedia,  virtual 
reality. 
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Required  Reusability  (RUSE) 


This  cost  driver  accounts  for  the  additional  effort  needed  to  construct  components  intended  for 
reuse  on  the  current  or  future  projects.  This  effort  is  consumed  with  creating  more  generic  design 
of  software,  more  elaborate  documentation,  and  more  extensive  testing  to  ensure  components  are 
ready  for  use  in  other  applications. 


Very  Low 

Low 

Nominal 

High 

Very  High 

Extra 

High 

RUSE 

none 

across 

project 

across  pro 
gram 

across 
product  line 

across 

multiple 

product 

lines 

Documentation  match  to  life-cycle  needs  (DOCU) 

Several  software  cost  models  have  a  cost  driver  for  the  level  of  required  documentation.  In 
COCOMO II,  the  rating  scale  for  the  DOCU  cost  driver  is  evaluated  in  terms  of  the  suitability  of 
the  project’s  documentation  to  its  life-cycle  needs.  The  rating  scale  goes  from  Very  Low  (many 
life-cycle  needs  uncovered)  to  Very  High  (very  excessive  for  life-cycle  needs). 


Very  Low 

Low 

Nominal 

High 

Very  High 

Extra 

High 

DOCU 

Many  life- 
cycle 
needs 
uncovered 

Some  life- 
cycle 
needs 
uncovered. 

Right-sized 
to  life-cycle 
needs 

Excessive 
for  life- 
cycle 
needs 

Very 

excessive 
for  life- 
cycle 
needs 

Z.S.2.2  Platform  Factors 

The  platform  refers  to  the  target-machine  complex  of  hardware  and  infrastructure  software 
(previously  called  the  virtual  machine).  The  factors  have  been  revised  to  reflect  this  as  described 
in  this  section.  Some  additional  platform  factors  were  considered,  such  as  distribution,  parallel¬ 
ism,  embeddedness,  and  real-time  operations.  These  considerations  have  been  accommodated  by 
the  expansion  of  the  Module  Complexity  ratings  in  Equation  3-15. 

Execution  Time  Constraint  (TIME) 

This  is  a  measure  of  the  execution  time  constraint  imposed  upon  a  software  system.  The  rating  is 
expressed  in  terms  of  the  percentage  of  available  execution  time  expected  to  be  used  by  the 
system  or  subsystem  consuming  the  execution  time  resource.  The  rating  ranges  from  nominal, 
less  than  50%  of  the  execution  time  resource  used,  to  extra  high,  95%  of  the  execution  time 
resource  is  consumed. 
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Very  Low 

Low 

Nominal 

High 

Very  High 

Extra 

High 

TIME 

50%  use 
of  available 
execution 
time 

70% 

85% 

95% 

Main  Storage  Constraint  (STOR) 

This  rating  represents  the  degree  of  main  storage  constraint  imposed  on  a  software  system  or 
subsystem.  Given  the  remarkable  increase  in  available  processor  execution  time  and  main 
storage,  one  can  question  whether  these  constraint  variables  are  still  relevant.  However,  many 
applications  continue  to  expand  to  consume  whatever  resources  are  available,  making  these  cost 
drivers  still  relevant.  The  rating  ranges  from  nominal,  less  that  50%,  to  extra  high,  95%. 


Very  Low 

Low 

Nominal 

High 

Very  High 

Extra 

High 

STOR 

50%  use 
of  available 
storage 

70% 

85% 

95% 

Platform  Volatility  (PVOL) 

“Platform”  is  used  here  to  mean  the  complex  of  hardware  and  software  (OS,  DBMS,  etc.)  the 
software  product  calls  on  to  perform  its  tasks.  If  the  software  to  be  developed  is  an  operating 
system  then  the  platform  is  the  computer  hardware.  If  a  database  management  system  is  to  be 
developed  then  the  platform  is  the  hardware  and  the  operating  system.  If  a  network  text  browser 
is  to  be  developed  then  the  platform  is  the  network,  computer  hardware,  the  operating  system, 
and  the  distributed  information  repositories.  The  platform  includes  any  compilers  or  assemblers 
supporting  the  development  of  the  software  system.  This  rating  ranges  from  low,  where  there  is  a 
major  change  every  12  months,  to  very  high,  where  there  is  a  major  change  every  two  weeks. 


Very  Low 

Low 

Nominal 

High 

Very  High 

Extra 

High 

PVOL 

major 
change 
every  12 
mo.;  minor 
change 
every  1  mo. 

major:  6 
mo.;  minor: 

2  wk. 

major:  2 
mo.; 
minor:  1 
wk. 

major:  2 
wk.; 

minor:  2 
days 

3.6.2.3  Personnel  Factors 
Analyst  Capability  (ACAP) 

Analysts  are  personnel  that  work  on  requirements,  high  level  design  and  detailed  design.  The 
major  attributes  that  should  be  considered  in  this  rating  are  Analysis  and  Design  ability. 
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efficiency  and  thoroughness,  and  the  ability  to  communicate  and  cooperate.  The  rating  should  not 
consider  the  level  of  experience  of  the  analyst;  that  is  rated  with  AEXP .  Analysts  that  fall  in  the 
15th  percentile  are  rated  very  low  and  those  that  fall  in  the  95th  percentile  are  rated  as  very  high. 


Very  Low 

Low 

Nominal 

High 

Very  High 

Extra 

High 

ACAP 

15th 

percentile 

35th 

percentile 

55th 

percentile 

75th 

percentile 

90th 

percentile 

Programmer  Capability  (PCAP) 

Current  trends  continue  to  emphasize  the  importance  of  highly  capable  analysts.  However  the 
increasing  role  of  complex  COTS  packages,  and  the  significant  productivity  leverage  associated 
with  programmers’  ability  to  deal  with  these  COTS  packages,  indicates  a  trend  toward  higher 
importance  of  programmer  capability  as  well. 

Evaluation  should  be  based  on  the  capability  of  the  programmers  as  a  team  rather  than  as 
individuals.  Major  factors,  which  should  be  considered  in  the  rating,  are  ability,  efficiency  and 
thoroughness,  and  the  ability  to  communicate  and  cooperate.  The  experience  of  the  programmer 
should  not  be  considered  here;  it  is  rated  with  AEXP.  A  very  low  rated  programmer  team  is  in  the 
15th  percentile  and  a  very  high  rated  programmer  team  is  in  the  95th  percentile. 


Very  Low 

Low 

Nominal 

High 

Very  High 

Extra 

High 

PCAP 

15th 

percentile 

35th 

percentile 

55th 

percentile 

75th 

percentile 

90th 

percentile 

Applications  Experience  (AEXP) 

This  rating  is  dependent  on  the  level  of  applications  experience  of  the  project  team  developing 
the  software  system  or  subsystem.  The  ratings  are  defined  in  terms  of  the  project  team  s 
equivalent  level  of  experience  with  this  type  of  application.  A  very  low  rating  is  for  application 
experience  of  less  than  2  months.  A  very  high  rating  is  for  experience  of  6  years  or  more. 


Very  Low 

Low 

Nominal 

High 

Very  High 

Extra 

High 

AEXP 

2  months 

6  months 

1  year 

3  years 

6  years 

Platform  Experience  (PEXP) 

The  Post- Architecture  model  broadens  the  productivity  influence  of  PEXP,  recognizing  the 
importance  of  understanding  the  use  of  more  powerful  platforms,  including  more  graphic  user 
interface,  database,  networking,  and  distributed  middleware  capabilities. 
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Very  Low 

Low 

Nominal 

High 

Very  High 

Extra 

High 

PEXP 

2  months 

6  months 

1  year 

3  years 

6  year 

Language  and  Tool  Experience  (LTEX) 

This  is  a  measure  of  the  level  of  programming  language  and  software  tool  experience  of  the 
project  team  developing  the  software  system  or  subsystem.  Software  development  includes  the 
use  of  tools  that  perform  requirements  and  design  representation  and  analysis,  configuration 
management,  document  extraction,  library  management,  program  style  and  formatting, 
consistency  checking,  etc.  In  addition  to  experience  in  programming  with  a  specific  language  the 
supporting  tool  set  also  effects  development  time.  A  low  rating  is  given  for  experience  of  less 
than  2  months.  A  very  high  rating  is  given  for  experience  of  6  or  more  years. 


Very  Low 

Low 

Nominal 

High 

Very  High 

Extra 

High 

LTEX 

2  months 

6  months 

1  year 

3  years 

6  year 

Personnel  Continuity  (PCON) 

The  rating  scale  for  PCON  is  in  terms  of  the  project’s  annual  personnel  turnover:  from  3%,  very 
high,  to  48%,  very  low. 


Very  Low 

Low 

Nominal 

High 

Very  High 

■m 

PCON 

48%  /  year 

24%  /  year 

12% /year 

6%  /  year 

3%  /  year 

3.6.2.4  Project  Factors 

Use  of  Software  Tools  (TOOL) 

Software  tools  have  improved  significantly  since  the  1970’s  projects  used  to  calibrate  COCOMO. 
The  tool  rating  ranges  from  simple  edit  and  code,  very  low,  to  integrated  lifecycle  management 
tools,  veiy  high. 
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Very  Low 

Low 

Nominal 

High 

Very  High 

Extra 

High 

TOOL 

edit,  code, 
debug 

simple, 
front  end, 
back  end 
CASE,  little 
integration 

basic  life 
cycle  tools, 
moderately 
integrated 

strong, 
mature  life 
cycle  tools, 
moderately 
integrated 

strong, 
mature,  pro 
active  life 
cycle  tools, 
well 

integrated 

with 

processes, 

methods, 

reuse 

Multisite  Deveiopment  (SiTE) 


Given  the  increasing  frequency  of  multisite  developments,  and  indications  that  multisite 
development  effects  are  significant,  the  SITE  cost  driver  was  added  in  COCOMO II.  Determining 
its  cost  driver  rating  involves  the  assessment  and  averaging  of  two  factors:  site  collocation  (from 
fully  collocated  to  international  distribution)  and  communication  support  (from  surface  mail  and 
some  phone  access  to  full  interactive  multimedia). 


Very  Low 

Low 

Nominal 

High 

Very  High 

Extra  High 

SITE; 

Communications 

Some 
phone,  mail 

Individual 
phone,  FAX 

Narrowband 

email 

Wideband 

electronic 

communicati 

on. 

Wideband 
elect, 
comm, 
occasional 
video  conf. 

Interactive 

multimedia 

Required  Development  Schedule  (SCED) 

This  rating  measures  the  schedule  constraint  imposed  on  the  project  team  developing  the 
software.  The  ratings  are  defined  in  terms  of  the  percentage  of  schedule  stretch-out  or 
acceleration  with  respect  to  a  nominal  schedule  for  a  project  requiring  a  given  amount  of  effort. 
Accelerated  schedules  tend  to  produce  more  effort  in  the  later  phases  of  development  because 
more  issues  are  left  to  be  determined  due  to  lack  of  time  to  resolve  them  earlier.  A  schedule 
compress  of  74%  is  rated  very  low.  A  stretch-out  of  a  schedule  produces  more  effort  in  the  earlier 
phases  of  development  where  there  is  more  time  for  thorough  planning,  specification  and 
validation.  A  stretch-out  of  160%  is  rated  very  high. 


Very  Low 

Low 

Nominal 

High 

Very  High 

Extra 

High 

SCED 

75%  of 
nominal 

85% 

100% 

130% 

160% 

27 


Table  3-14;  Post-Architecture  Cost  Driver  Rating  Level  Summary 


Very  Low 

Low 

Nominal 

■EiaHi 

Very  High 

Extra  High 

RELY 

slight 

inconve¬ 

nience 

low,  easily 

recoverable 

losses 

moderate, 

easily 

recoverable 

losses 

high  financial 
loss 

risk  to  human 
life 

DATA 

DB 

bytes/Pgm 

SLOC<10 

10  DIP  < 

100 

100  D/P< 
1000 

D/P  1000 

CPLX 

see  Table  3-13  I 

RUSE 

none 

across  project 

across  pro¬ 
gram 

across 
product  line 

across  multi¬ 
ple  product 
lines 

DOCU 

Many  life- 
cycle  needs 
uncovered 

Some  life- 
cycle  needs 
uncovered. 

Right-sized  to 

life-cycle 

needs 

Excessive  for 

life-cycle 

needs 

Very 

excessive  for 
life-  cycle 
needs 

TIME 

50%  use  of 
available 
execution 
time 

70% 

85% 

95% 

STOR 

50%  use  of 

available 

storage 

70% 

85% 

95% 

PVOL 

major  change 

every  12  mo.; 
minor  change 
every  1  mo. 

major:  6  mo.; 
minor:  2  wk. 

major:  2  mo.; 
minor:  1  wk. 

major:  2  wk.; 
minor:  2  days 

ACAP 

15th 

percentile 

55th 

percentile 

75th 

percentile 

90th 

percentile 

PCAP 

15th 

percentile 

35th 

percentile 

55th 

percentile 

75th 

percentile 

90th 

percentile 

PCON 

24%  /  year 

12%  /  year 

6%  /  ygar 

AEXP 

2  months 

6  months 

1  year 

3  years 

6  years 

PEXP 

2  months 

1  year 

3  years 

6  year 

LTEX 

2  months 

6  months 

1  year 

3  years 

6  year 

TOOL 

edit,  code, 
debug 

simple, 
frontend, 
backend 
CASE,  little 
integration 

basic  lifecycle 
tools, 

moderately 

integrated 

strong, 
mature 
lifecycle  tools, 
moderately 
integrated 

strong, 
mature, 
proactive  life 
cycle  tools, 
well 

integrated 

with 

processes, 

methods, 

reuse 

SITE: 

Colloc 

ation 

International 

Multi-city  and 
Multi¬ 
company 

Multi-city  or 
Multi¬ 
company 

Same  city  or 
metro,  area 

Same 
building  or 
complex 

Fuliy 

collocated 

SITE: 

Comm 

unicati 

ons 

Some  phone, 
mail 

Individual 
phone,  FAX 

Narrowband 

email 

Wideband 

electronic 

communicatio 

n. 

Wideband 
elect,  comm, 
occasional 
video  conf. 

Interactive 

multimedia 

SCED 

75%  of 
nominal 

85% 

100% 

130% 

160% 
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4.0  Numerical  Values  of  Scale  Factors  for  Early  Design  and  Post- 

Architecture 


A-Posteriori  Bayesian  Values  (1998) 
Scale  Factors 


Driver 

VL 

L 

N 

PREC 

6.20 

4.96 

3.72 

FLEX 

5.07 

4.05 

3.04 

RESL 

7.07 

5.65 

4.24 

TEAM 

5.48 

4.38 

3.29 

PMAT 

7.80 

6.24 

4.68 

Equations 
B  =  .91  + 0.01 

i 

TDEV  =  [3.67  X  ]„ 

=2MSIZE‘  -flPA-EM, 

/=! 

-or- 

=  2.94 . SIZE'  flED- EM, 


H  VH 

2.48  1.24 

2.03  1.01 

2.83  1.41 

2.19  1.10 

3.12  1.56 


(2.2) 


(2.6) 


XH 

0.00 

0.00 

0.00 

0.00 

0.00 
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5.0  Numerical  Values  of  Effort  Multipliers  for  Early  Design 


From  sdevnani@sunset.usc.edu  Sun  Aug  30  23:20:18  1998 

Date:  Mon,  17  Aug  1998  17:20:14  -0700 

From:  Sunita  Chulani  <sdevnani@sunset . use . edu> 

To:  awbrown@sunset.usc.edu,  Yu-Ting  Kao  <yutingk@scf .usc.edu> 
Subject:  Early  Design  Multipliers 


Here  are  the  Early  Design  Parameters 


Effort  Multipliers 


Driver 

XL 

VL 

L 

PERS 

2.12 

1.62 

1.26 

RCPX 

0.73 

0.81 

0.98 

PDIF 

0.87 

1.00 

PREX 

1.59 

1.33 

1.12 

FOIL 

1.43 

1.30 

1.10 

Equations 


B  =  .91  +  0.01xX^. 


TDEV  =  [3.67  X  (pjv/)(o-28+o.2x(B-.9i))  1^  SCEDVo 
^  •'  100 


N 

H 

VH 

XH 

1.00 

0.83 

0.63 

.50 

1.00 

1.30 

1.74 

2.38 

1.29 

1.81 

2.61 

1.00 

0.87 

0.71 

0.62 

1.00 

0.87 

0.73 

0.62 

(2.2) 

(2.6) 


^M_„„,=2.94.57Z£^.n  ED -EM, - 

/=i 

the  scale  factor  ratings  stay  the  same. 
-  Sunita 
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6.0  Post-Architecture  Scale  Factors  and  Effort  Multipliers 


From  sdevnani@sunset.usc.edu  Mon  Jun  29  09:29:09  1998 


Dr.  Horowitz  and  Jongmoon, 

Here  are  the  official  COCOMO  11.1998 
in  the  USC  COOCMO  11.1998  tool 

A-Posteriori  Bayesian  Values  (1998) 

Scale  Factors 


Driver 

VL 

L 

N 

PREC 

6.20 

4.96 

3.72 

FLEX 

5.07 

4.05 

3.04 

RESL 

7.07 

5.65 

4.24 

TEAM 

5.48 

4.38 

3.29 

PMAT 

7.80 

6.24 

4.68 

Effort 

Multipliers 

Driver 

VL 

L 

N 

RELY 

0.82 

0.92 

1.00 

DATA 

0.90 

1.00 

CPLX 

0.73 

0.87 

1.00 

RUSE 

0.95 

1.00 

DOCU 

0.81 

0.91 

1.00 

TIME 

1.00 

STOR 

1.00 

PVOL 

0.87 

1.00 

ACAP 

1.42 

1.19 

1.00 

PCAP 

1.34 

1.15 

1.00 

PCON 

1.29 

1.12 

1.00 

AEXP 

1.22 

1.10 

1.00 

PEXP 

1.19 

1.09 

1.00 

LTEX 

1.20 

1.09 

1.00 

TOOL 

1.17 

1.09 

1.00 

SITE 

1.22 

1.09 

1.00 

SCED 

1.43 

1.14 

1.00 

Equations 


B  =  .91  +  0.01xXf^. 

i 


values  that  need  to  be  incorporated 


H 

VH 

XH 

2.48 

1.24 

0.00 

2.03 

1.01 

0.00 

2.83 

1.41 

0.00 

2.19 

1.10 

0.00 

3.12 

1.56 

0.00 

H 

VH 

XH 

1.10 

1.26 

1.14 

1.28 

1.17 

1.34 

1.74 

1.07 

1.15 

1.24 

1.11 

1.23 

1.11 

1.29 

1.63 

1.05 

1.17 

1.46 

1.15 

1.30 

0.85 

0.71 

0.88 

0.76 

0.90 

0.81 

0.88 

0.81 

0.91 

0.85 

0.91 

0.84 

0.90 

0.78 

0.93 

0.86 

0.80 

1.00 

1.00 

(2.2) 


TDEV  =  [3.67  X  (PjV/)(0  28+0.2><(B-.91)) 


(2.6) 


PM =  2.94 •  SIZE’^  f\PA- EM, 

i=\ 

For  Effort  :  Multiplicative  Constant  =  2.94  and  Baseline  Exponent  =  0.91 
(This  replaces  1.01  in  the  COCOMO  11.1997  calibraiton) 

For  Schedule  :  Multiplicative  Constant  =3.67  and  Baseline  Exponent  = 
0.28 

(this  replaces  0.33  in  the  COCOMO  11.1997  Calibration) 
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L.  Appendix  2. 

Part  1 


CORADMO  Summary 
A.  Winsor  Brown 


Abstract 

The  COCOMO  RAD  MODEL  (CORADMO)  is  currently  implemented  in  two  parts:  a 
front  end  staged  schedule  and  effort  model,  COCOMO  Staged  Schedule  and  Effort 
MODEL  (COSSEMO),  and  a  back  end  RAD  model.  COSSEMO's  uses  a  different 
schedule  estimation  calculation  than  COCOMO  ITs  simple  one:  COSSEMO 's 
schedule  estimation  uses  a  more  complex  calculation  for  the  low  effort  situations, 
those  below  64  person-months.  At  this  time  there  are  no  other  COSSEMO  "drivers  ” 
besides  COCOMO  Il's  calculated  effort.  The  RAD  model  has  its  roots  in  the  results 

of  a  1997  CSE  Focused  Workshop  on  Rapid  Application  Development^ .  RAD  is 
taken  to  mean  application  of  any  of  a  number  of  techniques  or  strategies  to  reduce 
software  development  cycle  time.  Five  classes  of  strategies  whose  degree  of 
implementation  can  be  used  to  parameterize  a  schedule  estimate  given  an  effort 
estimate  produced  by  COCOMOII-1998  were  derived  from  the  Focused  Workshop ’s 
results.  These  strategies,  which  are  over  and  above  just  adding  people  to  the  task, 
include  development  process  re-engineering  (DPRS),  re-use  and  very  high  level 
languages  (RVHL),  collaboration  efficiency  (CLAB),  architecture  investment  and  risk 
Resolution  (REEL),  and  pre-positioning  of  assets  (PROS). 


1  B.  Boehm,  S.  Chulani,  and  A.  Egyed,  “Knowledge  Summary:  USC-CSE  Focused  Workshop  on  Rapid  Application 
Development,”  USC-CSE  Technical  Report,  June  1997. 
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1 .  Introduction 


The  evolution  of  CORADMO  and  its  companion/pre-processor  model  COSSEMO  has  its  roots  in  several  activities 
undertaken  by  the  Center  for  Software  Engineering:  COCOMO-II,  and  a  Rapid  Application  Development  Focused 
Workshop. 

1.1.  Another  step  in  the  evolution  of  COCOMO-II 

The  COCOMO-II  Model  Manual  provides  the  primary  motive  for  this  extension  of  COCOMO-II.  “As  COCOMO  II 
evolves,  it  will  have  a  more  extensive  schedule  estimation  model,  reflecting  the  different  classes  of  process  model  a 
project  can  use;  the  effects  of  reusable  and  COTS  software;  and  the  effects  of  applications  composition  capabilities.” 

1.2.  COCOMO  II  Schedule 

The  COCOMO-II  schedule,  as  presently  implemented  (COCOMO-II  1998)  reflects  a  waterfall  process  model,  and 
not  any  of  the  currently  accepted  alternatives  such  as  iterative,  spiral  or  evolutionary.  In  addition,  it  has  been 
observed  that  the  COCOMO-II’s  duration  calculation  seems  unreasonable  for  small  projects,  those  with  effort  under 
two  person  years.  Obviously,  COCOMO-II  does  not  address  any  of  the  Rapid  Application  Development  (RAD) 
strategies  that  are  being  employed  to  reduce  schedule  and  sometimes  effort  as  well. 

1.3.  COCOMO-II  Constructive  Staged  Schedule  &  Effort  Model  and 
Constructive  RAD  Schedule  Estimation  Model 

In  an  effort  to  overcome  these  shortfalls,  two  extensions  have  been  developed:  the  COCOMO-II 

Staged  Schedule  &  Effort  Model  (COSSEMO)  and  the  Constructive  RAD  schedule  estimation  Model  CoRADMo. 

2.  Improving  the  Classic  CoCoMo  Model  for  Schedule 

The  classic  CoCoMo  model  has  deficiencies  in  several  areas:  a  waterfall  predilection,  no  drivers  reflecting  modem 
schedule  reduction  efforts,  and  small-effort  projects. 

2.1.  New  Drivers 

In  CSE’s  Focussed  Workshop  #9  on  RAD,  a  RAD  Opportunity  Tree  of  strategies  was  presented.  The  strategies 
included  some  techniques  that  were  already  covered  by  the  drivers  of  COCOMO-II  as  well  as  several  that  were  not. 
An  analysis  of  these  new  drivers  produced  a  set  of  five  drivers  that  reflect  identifiable  behavioral  characteristics. 
These  were 

1 .  Reuse  and  Very  High-level  Languages  (RVHL) 

2.  Development  Process  Reengineering  (DPRS) 

3.  Collaboration  Efficiency  (CLAB) 

4.  Architecture,  Risk  Resolution  (RESL) 

5.  Prepositioning  Assets  (PPOS) 

These  new  drivers  are  reflected  in  the  annotated  “RAD  Opportunity  Tree  “  shown  in  Figure  1 . 
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Eliminating  Tasks 

Reducing  Time  Per  Task 

Ll 

Reducing  Single-Point  Failure  Risks 

c 

Reducing  Backtracking 

Activity  Network  Streamlining 

— 

Increasing  Effective  Workweek 

Better  People  and  Incentives 

L 

Transition  to  Learning  Organization 

Business  process  reengineering  -  O 
Development  process  reengineering  -  DPRS 
Reusing  assets  -  RVHL 
Applications  generation  -  RVHL 
Design-to-schedule  -  O 

Tools  and  automation  -  O 
Work  streamlining  (80-20)  -  O 
Increasing  parallelism  -  RESL 

Reducing  failures  -  RESL 
Reducing  their  effects  -  RESL 

Early  error  elimination  -  RESL 
Process  anchor  points  -  RESL 
Improving  process  maturity  -  O 
Collaboration  efficiency  -  CLAB 

Minimizing  task  dependencies  -  DPRS 
Avoiding  high  fan-in,  fan-out  -  DPRS 
Reducing  task  variance  -  DPRS 
Removing  tasks  from  critical  path  -  DPRS 

Prepositioning  resources  -  PPOS 
Nightly  builds,  testing  •  PPOS 
Weekend  warriors,  24x7  development  -  PPOS 
•  constraint 

-  O  0:  covered  by  classic  cube  root  model 


Figure  1.  Annotated  RAD  Opportunity  Tree 


2.2.  Duration  Calculation 

The  COCOMO-II  schedule,  as  presently  implemented  (in  COCOMO-II1998)  reflects  a  waterfall  process  model  and 
its  duration  calculation  seems  unreasonable  for  small  projects,  those  with  effort  under  two  person  years. 


2.2.1  COCOMO  II  Duration  Calculation 


The  COCOMO-II  duration  calculation  is  based  on  an  equation  that  has  demonstrated  historical  accuracy,  at  least  for 
large  projects. 


Months 


3 


erson-Months 


This  model  component  completely  breaks  down  at  very  low  efforts  (16  person-months  of  effort)  and  is  very 
questionable  below  a  few  person-years  of  effort. 


2.2.2  COSSEMO  Duration  Calculation 


COCOMO's  effort  and  schedule  estimates  are  focused  on  Elaboration  and  Construction  (the  Stages  between  ECO 
and  IOC.  Inception  corresponds  to  the  COCOMO's  "Requirements"  activity,  which  is  actually  an  additional  (fixed 
percentage)  effort,  above  and  beyond  the  effort  calculated  by  COCOMO. 
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equation  is 


TDEV=  (3.0  *  PMbar'XO.SS  +  0.2  *  (B-1.01))  *  SCED%/100 

where  TDEV  is  the  calendar  time  in  months  from  the  determination  of  a  product’s  requirements  baseline  to  the 
completion  of  an  acceptance  activity  certifying  that  the  product  satisfies  its  requirements.  PMbar  is  the  estimated 
person-months  excluding  the  SCED  effort  multiplier,  B  is  the  sum  of  project  scale  factors  (discussed  in  the  next 
chapter)  and  SCED%  is  the  compression  /  expansion  percentage  in  the  SCED  effort  multiplier. 

The  TDEV  calculations  mean  that  the  calculated  schedule  is  related,  approximately,  to  three  times  the  cube  root  of 
the  effort.  For  low-effort  situations,  especially  below  twenty  seven  (27)  person  months,  this  yields  a  very 
pessimistic  and  unlikely  duration  of  nine  (9)  months  applying  three  (3)  ESP  people.  As  a  result,  a  new  baseline 
schedule  equation  for  efforts  below  16  months  has  been  chosen  which  is  based  on  the  square-root  of  the  effort, 
yielding  equal  FSPs  and  schedule  months.  A  linear  interpolation  is  used  between  the  high-end  applicability  of  64 
person  months  (which  corresponds  to  a  schedule  of  14.4  months  for  a  lOOKsloc  EHART  using  1998  average  driver 
values),  and  the  low  end  point  of  16  person  months. 
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Figure  2.  Showing  linear  interpolation  between  cube  and  square  root 


2.3.  Process  Model 

The  COSSEMO  model  is  based  on  the  lifecycle  anchoring  concepts  discussed  by  Boehm^.  The  anchor  points  are 
defined  as  Life  Cycle  Objectives  (LCO),  Life  Cycle  Architecture  (LCA),  and  Initial  Operational  Capability  (IOC). 
An  augmented  illustration  based  on  one  from  the  Rational  Corporation^,  Figure  3  shows  the  stages  around  the 
anchor  points. 


Time 

◄ - ► 

LCO  LCA  IOC 


Stages 

Process  Activities 

Requirements  Capture 

Inception 

Elaboration 

Construction 

Transition 

Analysis  &  Design 

Activities  &  Implementation 

Representative  Test 

- 1 - 

r 

Amounts  ^  .... 

Supporting  Activities 

Management 

Environment  _ 

preliminary 

iteration(s) 

iter.  iter. 

#1  #2 

iter.  iter.  iter. 
#n  #n+1  #n+2 

iter.  Iter.  I 

#m  #m+l' 

Iterations 


Figure  3.  A  modem  lifecycle  model  with  anchor  points 


2  Barry  W.  Boehm,  “Anchoring  the  Software  Process,”  IEEE  Software,  13,  4,  July  1996,  pp.  73-82. 

3  Rational  Corp.,  "Rational  Objectory  Process  4.1  —  YourUML  Process",  available  at 
http://www.rational.com/support/techpapers/toratobJprcs/. 
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2.4.  Anchor  Points,  Stages  and  Activities 

The  diagram  shows  various  activities,  and  implies  iterations  and  the  relative  effort  and  duration  of  typical  cycles 
within  an  iteration.  The  following  table  provides  some  more  detail  on  the  relative  proportion  of  the  activities,  and 


some  details. 


COCOMO  II 
Submodel  Usage 

Early  Design Post-Architecture  Maintenance 

LCO  LCA  IOC 

Activities  \ 

Stage 

Inception 

Elaboration 

Construction 

Transition 

Requirements 

Capture 

Some 

usually 

Most,  peaks 
here 

Minor 

None 

Analysis  &  Design 

A  little 

Majority, 

mostly 

constant  effort 

Some 

Some,  for 
repair  during 
ODT&E 

Implementation 

Practically 

none 

Some,  usually 
for  risk 
reduction 

Bulk;  mostly  constant 
effort 

Some,  for 
repair  during 
ODT&E 

Test 

None 

Some,  for 
prototypes 

Most  for  unit  test, 
integration  test  and 
qualification  test. 

Some,  for 
repaired  code. 

Table  1 .  Stages,  Anchor  Points,  and  relative  amount  and  kind  of  Activities 


3.  Model  Overview 

There  are  two  parts  of  the  current  model,  COSSEMO  and  CORADMO.  They  both  assume  that  data  is  available 
from  a  COCOMO  II  model. 

3.1.  COCOMO  II  Constructive  Staged  Schedule  &  Effort  Model  (COSSEMO) 

The  COSSEMO  part  of  the  model  currently  has  no  drivers,  per  se.  The  model  does  allow  for  the  specification  of  the 
percentages  of  effort  and  schedule  to  be  applied  to  the  different  stages:  Inception,  Elaboration  and  Construction. 

The  predicted  effort  and  schedule  from  a  COCOMO  II  run  correspond  to  the  sum  of  the  Elaboration  and 
Construction  stages’  effort  and  schedule,  respectively.  The  percentages  of  effort  and  schedule  Elaboration  and 
Construction  stages  thus  total  100%  and  are  used  to  distribute  the  sum  accordingly.  The  percentages  of  effort  and 
schedule  for  the  Inception  stage  are  also  applied  to  the  COCOMO  II  run’s  effort  and  schedule,  respectively.^  Thus, 
the  sum  of  the  effort  or  schedule  for  three  stages  can  actually  total  more  than  100%  of  the  COCOMO  II  run  s  effort 
and  schedule. 

3.2.  Constructive  RAD  Schedule  Estimation  Model  (CORADMO) 

The  CORADMO  model  has  five  drivers.  Each  driver  has  both  rating  levels,  which  are  selected  by  a  user  based  on 
the  characteristics  of  the  software  project,  its  development  organization,  and  its  milieu.  There  are  numeric  schedule 
and  effort  multiplier  values  per  stage  for  each  rating  level.  The  rating  levels  are  described  in  detail  in  Part  2  of  this 
report,  which  corresponds  to  a  subset  of  the  information  gathering  worksheet  for  users  of  the  model  and  its  tools. 
The  rating  levels  and  their  corresponding  numerical  values  are  summarized  below  and  provided  in  full  detail  in  Part 
3  of  this  report. 
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3.2.1  Reuse  and  VHLLs  (RVHL) 

The  impact  of  re-use  of  3GL  production  code  is  handled  directly  in  the  COCOMO  II  model  via  the  re-use  sub-model 
and  its  effect  on  size.  This  CORADMO  driver  reflects  the  impact  of  re-use  of  code  (other  than  production  code) 
and/or  the  use  of  very  high  level  languages,  especially  during  the  Inception  and  Elaboration  stages.  Higher  rating 
levels  reflect  the  potential  schedule  compression  impacts  in  Inception  and  Elaboration  stages  due  to  faster 
prototyping,  option  exploration.  Clearly  this  impact  will  be  dependent  on  the  level  of  capability  and  experience  in 
doing  this,  such  as  Rapid  Prototyping  experience.  The  values  of  the  multipliers  corresponding  to  the  rating  levels 
are  the  same  for  both  effort  and  schedule;  this  implies  that  the  staff  level  (number  of  fiill  time  software  personnel)  is 
held  constant. 

3.2.2  Development  Process  Reengineering  and  Streamlining  (DPRS) 

The  schedule  impact  of  this  driver  reflects  the  inverse  of  the  level  of  bureaucracy  in  which  the  developers  must 
operate.  More  succinctly  stated,  this  driver  captures  the  degree  to  which  the  project  and  organization  allow  and 
encourage  streamlined  or  re-engineered  development  processes.  A  detailed  rating  level  scale  is  provided  for  this 
driver  (see  Part  3  of  this  report).  The  values  of  the  multipliers  corresponding  to  the  rating  levels  are  the  same  for 
both  effort  and  schedule;  Ais  implies  that  the  staff  level  (number  of  full  time  software  personnel)  is  held  constant. 

3.2.3  Collaboration  Efficiency  (CLAB) 

Teams  and  team  members  who  can  collaborate  effectively  can  reduce  both  effort  and  schedule;  those  that  don’t 
collaborate  effectively  have  increased  schedule  and  effort  (due  to  wasted  time).  Rather  than  invent  a  new  behavioral 
characteristic,  this  driver’s  rating  level  is  primarily  determined  by  an  appropriate  combination  of  COCOMO  II  Post- 
Architecture  SITE  and  TEAM  driver  ratings  and  the  PREX  Early  Design  driver  ratings.  The  SITE  rating  needs  to 
be  augmented  by  the  team’s  collaboration  tool  maturity  and  experience.  The  effects  of  collaboration  tools  are 
expected  to  help  in  domain  analysis,  option  analysis,  and  negotiation.  A  detailed  rating  level  process  and  scale  is 
provided  for  this  driver  (see  Part  3  of  this  report).  The  values  of  the  multipliers  corresponding  to  the  rating  levels 
are  the  same  for  both  effort  and  schedule;  this  implies  that  the  staff  level  (number  of  foil  time  software  personnel)  is 
held  constant. 

3.2.4  Architecture  /  Risk  Resolution  (RESL) 

The  COCOMO  II  Architecture  /  Risk  Resolution  driver  (RESL)  enables  parallel  construction  activities  without  the 
COCOMO  II  assumed  effect  of  increased  integration  and  testing  costs.  There  is  not  any  impact  on  the  effort  or 
schedule  in  the  Inception  and  Elaboration  stages.  There  is  no  change  in  effort  because  of  RESL,  only  potential  for 
schedule  compression  at  higher  RESL  ratings.  For  this  driver  to  be  effective,  it  is  assumed  that  a  higher  level  of 
staffing  is  available  and  used  during  construction.  Thus  the  multipliers  corresponding  to  the  rating  levels  are  not  the 
same  for  both  effort  and  schedule. 

3.2.5  Prepositioning  Assets  (PPOS) 

This  driver  reflects  the  degree  to  which  assets  are  pre-tailored  to  a  project  or  physically  pre-positioned  and  furnished 
to  the  project  for  use  on  demand.  The  assets  include  skilled  or  particularly  knowledgeable,  people’s  skill-level 
increases,  and  pro-active  team-building.  The  assets  that  are  being  pre-positioned  also  include  processes  and  tools, 
and  architecture  and  componentry.  In  order  to  take  advantage  of  PPOS,  the  organization  must  either  be  taking  a 
product-line  approach  or  have  made  a  3,  6  or  10%  pre-inception  effort  investment!  PPOS  multipliers  reflect  the 
increased  effort  associated  with  the  pre-positioning  activities  as  well  as  the  corresponding  decrease  in  schedule  and 
increased  personnel  required. 

4.  Implementation  Models 

There  are  four  implementations  of  the  CORADMO/COSSEMO  model  at  this  time.  The  logical  implementation 
model  shows  how  the  various  drivers  and  models  interrelate.  The  physical  implementation  model  shows  how  the 
logical  implementation  model  has  been  realized  in  spreadsheets,  both  the  standalone  spreadsheet  extension  and  the 
multiple  parallel  version  that  is  part  of  the  Technology  Impact  Analyzer.  The  first  three  of  these  models  are  shown 
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below.  The  fourth  implementation  model  is  described  in  detail  in  the  Volume  1  of  the  KBS  A  Report. 

4.1.  Logical  COCOMO II  RAD  Extension 

Figure  4  shows  a  conceptual  logical  block  diagram  for  implementation  of  the  RAD  Model.  It  assumes  that  the 
regular  COCOMO  II  implementation  is  extended  with  stage  distributions  which  are  potential  driven  by  language 
level  (e.g.  3GL  or  4GL),  experience,  etc.  The  output  of  COCOMO  II  is  used  as  a  baseline  for  effort  and  schedule 
by  the  RAD  Extension.  The  stage  distributions  extension  allocates  the  baseline  effort  and  schedule  by  stage.  The 
RAD  extension  itself  is  controlled  by  the  five  drivers  (discussed  in  section  3),  resulting  m  the  RAD  effort  and 
schedule  by  stage. 


Figure  4.  Logical  Implementation  Model 


4.2.  Physical  COCOMO  II  RAD  Extension 

Figure  5  shows  the  shows  the  current  implementation  strategy  for  the  COCOMO  II  RAD 
leftt  box  represents  the  COCOMO  11.98  model  as  Implemented  by  COCOMO.exe,  self-identified  as  COCOMO 
II.  1998.0”  in  its  “About  USC-COCOMOII”  dialog  box.  Also  part  of  the  COCOMO  II  implementation  suite  is  a 
spreadsheet  called  COCOMO.xls  which  is  designed  to  import  two  CSV  files  that  can  be  exported  fi-om  ^ 
COCOMO.exe  and  make  their  information  available  in  spread  sheet  form  (it  also  generates  many  useful  charts  and 
graphs  of  the  data).  The  baseline  effort  and  schedule  as  well  as  the  values  for  all  the  drivers  are  acquired  the 
COSSEMO  Extension  by  links  to  the  COCOMO.xls  spreadsheet.  The  COSSEMO  Extension,  which  is  actually 
implemented  as  part  of  the  RAD  extension  (CoRADMo.xls)  distributes  the  effort  (with  no  SCED  impact)  ^d 
schedule  for  subsequent  operation  by  the  RAD  extension  proper.  Only  the  five  new  RAD  drivers  need  to  be  input 
into  the  RAD  extension:  RESL  is  actually  acquired  fi-om  the  COCOMO.xls  spreadsheet  via  links,  although  that 
value  can  be  over-ridden  by  the  user. 
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Figure  5.  Physical  Implementation  Model 


4.3.  Stand-alone  Spreadsheet  Implementation 

Figure  and  Figure  2  contain  a  stand-alone  implementation  of  the  COSSEMO  and  CORADMO  extensions. 
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Figure  6.  The  COSSEMO  extension  and  RAD  Driver  input  portion  of  CORADMO.xls 
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COnsSTJCtixe  R«D  schedJe  estitrafion  MOdel  (CoRADMo)  Devdopmert 


Sheet:  EDSPO-Dev 


Figure  7.  The  RAD  extension  calculation  and  display  of  Schedule  and  Effort 


43 


Appendix  2,  Part  2 
CORADMO  Drivers  &  Rating  Scales 


A.  Winsor  Brown 
AWBrown@sunset.USC.edu 
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Outline 


The  five  explicit  drivers 

•  Reuse  and  Very  High  Level  Languages  (VHLL)  (RVHL) 

•  Development  Process  Reengineering  (DPRS) 

•  Collaboration  Technology  (CLAB) 

•  Architecture,  Risk  Resolution  (RESL) 

•  Prepositioning  Assets  (PPOS) 

Each  is  presented  with 

•  Major  factors  influencing  selection 

•  Statement  of  applicability  to  effort  or  schedule  or  both 

•  Rating  levels  to  Numeric  value  conversion  tables 
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Reuse  and  VHLLs  (RVHL) 

Standard  3GL  module  reuse:  no  adjustment 

Schedule  compression  in  Inception  and  Elaboration 
stages  due  to  faster  prototyping,  option  exploration 

•  effect  depends  on  level  of  capability  and  experience  in 
doing  this  (similar  to  Rapid  Prototyping  experience) 

•  same  effect  on  effort;  staff  level  held  constant 


Schedule  and 

Rapid  Prototyping  Experience  Level  | 

Effort  Multipliers 

v*-  1 

L 

N 

H 

VH 

inception 

m 

1.0 

.98 

.94 

.90 

Eiaboration 

WBm 

1.0 

.99 

.97 

.95 

Construction 

1.0 

1.0 

1.0 

1.0 

1.0 
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Development  Process  Reengineering  and 

Streamlining  (DPRS) 

Detailed  rating  scale  provided  below 

Gains  depend  on  current  level  of  bureaucracy 

•  Same  effect  on  effort;  staff  level  held  constant 


Schedule  and  Effort  Multipliers 

Inception 

Elaboration 

Construction 

VL  -  Heavily  Bureaucratic 

1.20 

1.15 

1.15 

L  -  Bureaucratic 

1.08 

1.06 

1.06 

N  -  Basic  good  business  practices 

1.0 

1.0 

1.0 

H  -  Partiy  streamlined 

.96 

.98 

.98 

VH  -  Fully  streamlined 

.90 

.95 

.95 
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DPRS  Rating  Scale 


VL  L  N  H  VH 


Number  of 
approvals  required 
per  task 

Excessive 

Occasionaliy 

Reduced 

L.ii 

Mature 

Actively 

Reduced 

Actively 

Minimized 

Time  taken 
per  approval 

Excessive 

Occasionaliy 

Reduced 

Mature 

Actively 

Reduced 

Actively 

Minimized 

Reduced  task 
dependencies, 
critical  path  tasks 

None 

Little 

Mature 

Tech. 

Adopted 

Advanced 

Tech. 

Adopted 

Pioneering 

Followup  to  expedite 
task  completion 

None 

Little 

Encouraged 

Emphasized 

Strongly 

Emphasized 

Process 
measurement  & 
streamlining 

None 

Little 

Mature 

Tech. 

Adopted 

Advanced 

Tech. 

Adopted 

Pioneering 
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Collaboration  Efficiency  (CLAB) 

Detailed  rating  scale  provided 

•  Judgement-based  average  of  COCOMO  II  ratings: 

SITE,  TEAM  &  PREX 

•  SITE  ratings  also  include 

-  collaboration  tool  maturity,  experience 

-  scope  effects:  domain,  negotiation,  option-analysis  tool 
support 

Same  effect  on  effort;  staff  level  held  constant 


Schedule  &  Effort 

VL 

L 

N 

H 

VH 

EH 

Multipliers 

Inception 

1.21 

1.10 

1.00 

0.93 

0.86 

0.80 

Elaboration 

1.15 

1.07 

1.00 

0.95 

0.90 

0.86 

Construction 

1.10 

1.05 

1.00 

0.98 

0.95 

0.93 
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CLAB  Rating  Scale 


Judgement-based  average  of  COCOMO II  factors 

•  SITE 

•  TEAM 

•  PREX 


VL 

L  , 

N 

H 

VH 

EH 

SITE 

<==  COCOMO  II  Post-Arch.  Ratings  ==> 

plus  negotiation/tradeoff  tools 
basic  advanced 

TEAM 

A 

II 

II 

II 

A 

COCOMO  II  Scale  Factor  Ratings  ===» 

_ ^ ^ _ 1 

PREX 

(EL  &  VL)  <===  <==  <===  COCOMO  II  Early  Design  Ratings  ===>  ===>  ===> 
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Architecture  /  Risk  Resolution  (RESL) 

Same  as  COCOMO  II  RESL  rating  scale 

Enables  parallel  construction 

•  Assumes  higher  level  of  staffing  available  and  used 

(case  b  &  c  on  next  page) 

•  Otherwise  no  schedule  compression  (case  a  on  next 
page) 


Schedule 
Multipliers 
(Effort  Unchanged) 

VL 

L 

N 

H 

VH 

EH 

inception 

1.0 

1.0 

1.0 

Elaboration 

1.0 

1.0 

IB 

1.0 

1.0 

Construction 

la 

1.0 

11 

.91 

.83 
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Prepositioning  Assets  (PROS) 

Degree  to  which  assets  are  pre-tailored  to  project 
and  furnished  to  project  for  use  on  demand 

•  People  skills  and  teambuilding 

•  Processes  and  tools 

•  Architecture  and  componentry 

Requires  product-line  approach 

or  added  (3, 6, 10%)  pre-LCO  (e.g.  Inception)  effort 
investment 


PM/I\II=P  Multipliers 

N 

H 

VH 

EH 

Rating 

Basic  project 
legacy,  no 
tailoring 

Some 

prepositioning 
&  tailoring 

Key  items 
prepositioned 
&  tailored 

All  items 
prepositioned 
&  tailored 

Inception 

Elaboration 

Construction 

1.0/1 .0=1.0 
10/1.0=1.0 

1.0/10=1.0 

1.03/.93=111 

1.03/.93=1.11 

1.03/.93=111 

1.06/.86=123 

1.06/.86=1.23 

1.06/.86=1.23 

11/.80=1.37 

1.1/.80=1.37 

1.1/.80=1.371 

1  Interpretation  of  (Construction, EH)  table  entry;  PM=1.1  (effort  multiplier;  person 
months): 

M=0.80  (schedule  multiplier;  months);  P=1.37  (FSP  multiplier;  persons) 
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Appendix  2,  part  3 
CORADMO  and  COSSEMO  Driver 


1.  COCOMO  stage  Schedule  and  Effort  MODEL  (COSSEMO) 

COSSEMO  is  based  on  the  lifecycle  anchoring  concepts  discussed  by  Boehm^  The  anchor 
points  are  defined  as  Life  Cycle  Objectives  (LCO),  Life  Cycle  Architecture  (LCA),  and  Initial 
Operational  Capability  (IOC).  An  enhanced  version  of  an  illustration  from  Rational  Corporation^ 
showing  the  stages  around  the  anchor  points  is  shown  below. 

Time 


◄ - 

LCO  LCA 


IOC 


► 


activities  & 
r  epresentative 
a  mounts 


Stages 

‘  Process  Activities 

Requirements  Capture 

Analysis  &  Design 

Implementation 
Test _ 

Supporting  Activities 

Management 

Environment  _ 

Deployment 


Inception 

Elaboration 

Construction 

Transition 

i  ! 

I 

_  — 

_  1 

_ 

_ 

preliminary  |  iter  iter. 
iteration(s)  #1  #2 

iter.  iter.  iter.  |  Iter.  Iter.  I 

#n  #n+1  #n+2  1  #m  #m+1> 

iterations 


The  correspondence  between  COSSEMO’s  &.  CORADMO's  "Stages'",  COCOMOII’s  submodels 
and  the  life  cycle  anchor  points  is  shown  in  the  following  table  along  with  an  indication  of  the 
relative  amounts  of  the  different  activities. 


'  Constructive  RAD  schedule  and  effort  Model 
^  COCOMO-II  Staged  Schedule  and  Effort  Model 

^  Barry  W.  Boehm,  “Anchoring  the  Software  Process,”  IEEE  Software,  13, 4,  July  1996,  pp.  73-82 

^  Rational  Corp.,  "Rational  Objectory  Process  4.1  -  Your  UML  Process",  available  at 
http;//www.rational.com/support/techpapers/toratobjprcs/. 

^  COSSEMO  &  CORADMO  use  the  word  "stage"  so  it  is  not  confused  with  the  classic  waterfall  phases: 
Requirements,  Analysis,  Design,  Code,  Test  and  Maintenance. 
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CORADMO  and  COSSEMO  Driver 


COCOMO  II 
Submodel  Usage 

/ 

Early  Design  /  Post-Architecture 

Maintenance 

LCO  LCA  IOC 

Activities  \ 

Stage 

Inception 

Elaboration 

Construction 

Transition 

Requirements 

Capture 

Some  usually 

Most,  peaks 
here 

Minor 

None 

Analysis  &  Design 

A  little 

Majority, 

mostly 

constant  effort 

Some 

Some,  for  repair 
during  ODT&E 

Implementation 

Practically 

none 

Some,  usually 
for  risk 
reduction 

Bulk;  mostly  constant 
effort 

Some,  for  repair 
during  ODT&E 

Test 

None 

Some,  for 
prototypes 

Most  for  unit,  integration 
and  qualification  test. 

Some,  for  repaired 
code. 

COCOMOII's  effort  and  schedule  estimates  are  focused  on  Elaboration  and  Construction  (the 
stages  between  LCO  and  IOC.  Inception  corresponds  to  the  COCOMO's  "Requirements" 
activity  in  a  waterfall  process  model.  COCOMO’s  effort  for  the  “Requirements”  activity  is  an 
additional,  fixed  percentage  of  the  effort  calculated  by  COCOMO  for  the  development  activities. 
The  table  also  indicates  the  areas  in  which  the  COCOMO  II  Early  Design  and  Post-Architecture 
submodels  are  normally  used. 


CORADMO  and  COSSEMO  Driver 


Allocations 

1  .A.l .  Percentage  Effort  per  Stage.  Allocate  the  effort  (person  months)  used  in  each  of  the 
stages  as  a  percentage  of  the  total  effort  during  Elaboration  and  Construction.  The  sum  of  the 
percentages  of  Elaboration  and  Construction  should  be  100%.  The  effort  during  Inception  (as  a 
percentage  of  total  Elaboration  and  Construction)  is  added  to  get  the  Total  lE&C  which  should 
be  greater  than  100%. 


LCO  LCA  IOC 

Stage 

Inception 

Elaboration 

Construction 

Total  E  &  C 

Total  I E  & 
C 

%Effort 

100% 

I.A.2.  Percentage  Schedule  per  Stage.  Allocate  the  schedule  (calendar  months)  for  each  of  the 
stages  as  a  percentage  of  the  total  schedule  during  Elaboration  and  Construction.  The  sum  of 
Elaboration  and  Construction  should  be  100%.  The  schedule  during  Inception  (as  a  percentage 
of  total  Elaboration  and  Construction)  is  added  to  get  the  Total  lE&C  which  should  be  greater 
than  100%. 


LCO  LCA  IOC 

Stage 

Inception 

Elaboration 

Construction 

Total  E  &  C 

Total  I  E  & 
C 

%Schedule 

100% 

I.A.3.  Person-Power  per  Stage.  Indicate  the  average  number  of  people  actually  working  during 
this  period  of  each  of  the  stages.  If  the  loading  was  not  approximately  constant  during  the  period 
except  for  typical,  limited  ramp-ups,  please  indicate  the  degree  of  variation  by  providing  the 
Persons-Max  and  Persons-Min,  and  the  number  of  months  with  that  number  of  people  (max  and 
min,  respectively).  NOTE:  summing  persons  across  stages  is  illogical  and  incorrect. 


CORADMO  Driver  Value  Determination  Worksheet 


LCO  LCA  IOC 

Stage 

Inception 

Construction 

Total  E  &  C 

Total  I E  &  C 

Person, 

Average 

X 

X 

Heads 

Months 

Heads 

Months 

Heads 

Months 

X 

X 

Persons, 

Maximum 

X 

X 

Persons, 

Minimum 

X 

X 
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CORADMO  Driver  Value  Determination  Worksheet 


2.  COCOMO  RAD  MODEL  (CORADMO) 

The  intent  of  the  COCOMO  II  RAD  model  is  to  calculate/predict  the  schedule  (months,  M), 
personnel  (P),  and  adjusted  effort  (person-months,  PM)  based  on  the  distribution  of  effort  and 
schedule  to  the  various  stages,  and  impacts  of  the  selected  schedule  driver  ratings  on  the  M,  P, 
and  PM  of  each  stage. 

2  A.  1 .  Reuse  and  VHLL’s  (RVHL)  The  degree  to  which  re-use  of  other  than  code  and/or  very 
high  level  languages  are  utilized.  This  driver  reflects  schedule  compression  in  Inception  and 
Elaboration  stages  due  to  faster  prototyping  or  option  exploration.  The  rating  for  this  driver 
depends  on  the  amount  of  Rapid  Prototyping  Experience  the  development  team  has  had  in  the 
domain  of  the  project  being  evaluated.  Since  the  rating  applies  to  the  team,  it  must  include  the 
experience  of  the  managers  and  team  leaders  and  their  experience  takes  precedence  over  the 
average  of  the  rest  of  the  team  wnrUne  in  the  Inception  and  Elaboration  phases. 


1  RVHL 

V*fy  Cow 

Law 

Nominal 

High 

VeiyHlgh 

Don't 

Know 

N/A-Not 

AppHeable 

none 

On  average,  penoonel 
have  experience  on  less 
than  one  recent  project 
using  Rapid 
Prototyping 

most  personnel  have 
worked  on  more  than 
one  project  using 
Rapid  Prototyping 

on  average,  personnel 
have  worked  on  nnore 
than  two  projects  using 
Rapid  Prototyping 

all  personnel  have  worked 
on  at  least  three  projects 
using  Rapid  Prototyping 
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rationale: 
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CORADMO  Driver  Value  Determination  Worksheet 
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involves  the  use  and  combination  of  numerical  equivalents  of  the  rating  levels.  Specifically,  a  Very  Low  Post- Architecture  cost 
driver  rating  corresponds  to  a  numerical  rating  of  1,  Low  is  2,  Nominal  is  3,  High  is  4,  Very  High  is  5,  and  Extra  High  is  6.  For 
the  combined  Early  Design  cost  drivers,  the  numerical  values  of  the  contributing  Post- Architecture  cost  drivers  are  summed, 
and  the  resulting  totals  are  allocated  to  an  expeinded  Early  Design  model  rating  scale  going  from  Extra  Low  to  Extra  High.  The 


CORADMO  Driver  Value  Determination  Worksheet 
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CORADMO  Driver  Value  Determination  Worksheet 


CORADMO  Driver  Value  Determination  Worksheet 
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M.  Appendix  3 

Impact  Analysis  Worksheets 
and  Calculations 
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Technology  Impact  Analyzer  -  Individual  CoCoMoll  Scale  Factors  &  Effort  Multiplier  values  with  Rationales  over  time:  1998, 2006  &  2013 

_ PREC:  Precedentedness 

Driver  Basellne|CDa+SbDC■^1^KG0^^8j<Ge^l•1<KDg^^8|<De+ii  Kg-i-S  KO+IS  E9-t-8  EK«48 

PREC  default  3.06  2.80  2.50  2.50  2.00  2.80'  2.50  2.50  2.00  2.50  2.00  2.50  2.00 
PREC  new  i  I  _ _ _ _ _ _ 
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App-3-1--CII  Drivers 


App-3-1--CII  Drivers 


App-3-1--CH  Drivers 
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App-3-1-*CII  Drivers 


Technology  Impact  Analyzer  -  Individual  CoCoMoll  Scale  Factors  &  Effort  Multiplier  vaiues  with  Rationales  over  time:  1998, 2006  &  201 3 

RUSE:  Development  for  Reuse _ 

„  BaseHnelCDO+ebPe-t-ljKGC+BkGa^lflKDg+ekDan-lj  KC-^B  iKe^lsl  Eg+8  |Ea4l5|EK9-^BbKe-t-15 
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App-3-1--CII  Drivers 
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App-3-1-CII  Drivers 


App-3-1--CII  Drivers 
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AEXP:  Application  Experience 

App-3-1--Cn  Drivers 


Technology  Impact  Analyzer  --  Individual  CoCoMoll  Scale  Factors  &  Effort  Multiplier  values  with  Rationales  over  time;  1998, 2006  &  2013 
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App-3-1--Cll  Drivers 


App*3-1--CII  Drivers 


Technology  Impact  Analyzer  -  Individual  CoCoMoll  Scale  Factors  &  Effort  Multiplier  values  v>rith  Rationales 

_ SCED:  Required  Development  Schedule 
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APP-3-1--CII  Drivers 


Technology  Impact  Analyzer  -  Individual  CoCoMoll  Scale  Factors  &  Elfort  Multiplier  values  with  Rationales  over  time:  1998, 2006  &  201 3 
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and  reduced  software  understanding  penalties  due  to  software  understanding  technology 

EK:  Gains  over  E  due  to  stronger  KB  application  generator  technology  _ 

Results  are  consenrative,  particularly  for  EDCS,  as  maintenance  savings  would  be  greater  than  development  savings, 
due  to  reductions  in  amount  of  software  understanding,  redesign,  recode,  and  retest  effort. 
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App-3-1--CII  Drivers 


Technology  Impact  Analyzer  -  COCOMO-II.1998  Aggregate  Projected  Driver  Data  and  Calculations 


Tech  Impact  Analyzer:  COCOMOII-1998  Scale  Factors  &  Effort  Multipliers  --  Now,  +8  &  +15  years 


COCOMO II  data  (from  COCOMO II  Drivers)  and  calculations 
Factors  into  future  _ 
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Technology  Impact  Analyzer  -  Individual  RAD  Schedule  Multiplier  values  and  Rationales  over  time  (now,  -r-8  and  +1 5  years;  1 998. 2006  and  201 3) 
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App-3-3--RAD  Drivers 
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Technology  Impact  Analyzer  --  Individual  RAD  Schedule  Multiplier  values  and  Rationales  over  time  (now,  +8  and  +15  years;  1998,  2006  and  2013) 
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Technology  Impact  Analyzer  -  Individual  RAD  Schedule  Multiplier  values  and  Rationales  over  time  (now,  +8  and  +1 5  yeare;  1 998, 2006  and  201 3) 
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App-3-3--RAD  Drivers 


(0 

c 

o - 

O _ 

oa 

c  ®  o 
o}£.- 
■•*=  ?  S 

s2 


<D  s  2 
o  ®  2 


W  «r- 

c  77  o> 

.2  ®  cJ 

(/)  00  in 

O  i  o> 

®  ^ _ 

n  £  ” 

CO  Q  __ 

9  “  ® 

0-  9  S 


=  Q. 

ts  ® 

3  .£ 

■o  — 

S  % 

^  P 


® 

SI 

0) 

-  g- 

o 

-M.  Q. 


i2  ** 
^  «) 
M  C 

Ss 

c  0 
a  ^ 


lO 

o 

to 

O 

to 

o 

o 

8 

8 

o> 

O) 

CM 

CM 

CM 

•r" 

O  ^ 
o  o 

s  ^ 

c  « 
«o  > 

75  ^ 

1 - 

e  o 

1  ^ 
8  I 
g> 

^  (D  I 
«  o> 
.£  c 
-an 
o>  *r 
^  o> 
c  c 
a  o 
o  — 
"  S  ® 

-  .2  o 

CO  0) 


o  ^ 
■C  S' 

S  s 

«  •£ 

~  C 

a  E 

E  -S 

O  D. 

■o  E 

S  8 


f  ® 

E  = 

®  n 
c  o>- 

1  § 
■8  1. 
■O  ® 

®  UJ 

o  7 

®  ra  - 
■6  "S 
n  ® 

JS  i 

>  ®  ■ 

Q  P 

i 

^  g 

CO  o 
C  CM 


8  1^ 


o  *?  •? 
^  <n  u) 
*  o  o 

UJ  £  £ 

— •  o.  0. 


Q  D  0  .. 

O  ^  ^  ^  UJ  UJ 


99 


App-3-3-RAD  Drivers 


Technology  Impact  Analyzer  --  Individual  RAD  Schedule  Multiplier  values  and  Rationales  overtime  (now,  +8  and  +15  years;  1998, 2006  and  2013) 


(0 

c 

o 

O 

02$ 

c 

g 

s 

2 

o 

Si 

td 

LU 


(0 

(D 

W 

tn 

< 


to 

(D 


CO 

O 

GL 

0. 


O 

3= 

IIJ 


■c 

o 

CL 

Gl 

3 

to 

■£ 

to 

a> 

"S 

c 

0 

c 

i 

3 

•o 

S 

Q. 

•o 

C 

(0 

o 

to 

3 

o 

"S 

to 

to 

a 

O 

o 

O 

■D 

C 

(0 

T5 

S 

o 

E 

E 

o 

o 

w 

■3 

a 

E 

c 

s 

PROS  Projection  Rationales  (repeated) 

Some  lonq-ranqe  gains  over  CD  via  knowiedge-based  product  line  process 

0) 

<D 

Same  as  KG  in  2006;  compiementary  KD  and  KG  gains  in  2013 

0 

Q. 

0' 

w 

3 

O 

s 

ic 

E 

0 

c 

■0 

E 

o 

■3 

■3 

0 

O 

c 

0 

1 

0 

> 

O 

O 

0 

S 

to 

c 

0 

3> 

E 

0 

O 

c 

3) 

OT 

Same  gains  over  CD  via  domain  architectures  and  assets 

w 

o 

CM 

c 

0 

c 

0 

o 

O 

•3 

C 

0 

UJ 

0 

E 

0 

E 

0 

Q. 

E 

o 

u 

ttT 

o 

o 

CM 

,c 

lii 

to 

0 

0 

E 

0 

(0 

> 

CO 

c 

CO 

3) 

a 

u 

c 

3) 

CO 

Q 

O 

d 

d 

lij 

2^ 

UJ 

100 


sjeAMQ  avu-e-e-ddv 


Individual  RAD  Schedule  Multiplier  values  and  Rationales  over  time  (now,  +8  and  +15  years;  1998,  2006  and  201 3) 
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Technology  Impact  Analyzer  --  Individual  RAD  Schedule  Multiplier  values  and  Rationales  overtime  (now,  +8  and 

+15  years;  1998.  2006  and  2013) 
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N.  Appendix  4. 

KBS  A  ADM  Evaluation 

Prasanta  Bose 
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N.l  Introduction 


The  KBS  A  Advanced  Development  Model  developed  as  part  of  the  Rome 
Laboratory’s  Knowledge-Based  Software  Assistant  effort  is  aimed  at  improving  software 
development  productivity  and  software  quality.  The  fundamental  approach  in  achieving 
the  above  goal  is  providing  automated  support  that  mediates,  automates  and  documents  all 
activities  throughout  the  development  lifecycle  for  both  individual  developers  and  teams  of 
developers.  The  challenge  is  building  such  computer-based  assistants  as  elaborated  in  the 
KBSA  program  vision  [Green  et  al.,  1983]. 

The  key  concept  to  meeting  the  above  challenge  is  based  on  the  understanding  that  the 
software  development  is  a  knowledge  intensive  activity.  Creating  large  software  based 
systems  requires  knowledge  of  the  domain  (typically  multi-disciplinary  in  nature),  the 
knowledge  of  the  process  context,  knowledge  of  existing  components  and  hardware,  and 
personal  resources.  The  KBSA  approach  is  then  to  provide  means  for  capture  and  effective 
use  of  such  knowledge  with  the  goal  that  such  use  of  such  knowledge  by  the  stakeholders 
will  lead  to  timely  production  of  high-quality  software. 

Given  the  above  understanding,  the  key  idea  in  the  KBSA  approach  is  exploiting 
artificial  intelligence  (AI)  concepts  and  representations  to  capture  and  use  knowledge.  The 
different  types  of  product  specific  knowledge  are  user  requirements,  system  specifications, 
code,  test  scenarios  and  documentation.  Process  specific  knowledge  corresponds  to  the 
software  development  plans,  resources  and  status  of  the  project.  Some  major  problems 
here  are:  a)  integrated  usage  of  the  knowledge  [Selfridge,  1992]  b)  managing  change  and 
c)  managing  complexity.  Significant  progress  has  been  made  in  addressing  the  above 
problems  individually  [Johnson  et  al.,  1991;  Mi  et  al.,  1990;  Smith,  1991].  The  ADM 
builds  on  such  advances  to  provide  an  integrated  set  of  concepts  and  tools  that  address  the 
problems  within  a  single  framework.  In  the  following  subsections  we  elaborate  on  the 
problems  that  ADM  addresses,  and  present  our  approach  to  evaluating  it. 
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N.1.1  ADM  Evaluation:  Approach 

The  focus  of  this  report  is  on  the  analytic  evaluation  (via  case  studies)  of  the  ADM 
support  concepts.  The  approach  to  evaluating  ADM  involves 

a)  Identifying  the  underlying  representational  constructs  for  capturing  different 
types  of  knowledge  and  operations  and  functional  features  based  on  those 
constructs  in  the  ADM  framework, 

b)  Performing  the  usage  analysis  of  such  representational  constructs  and 
features  in  software  development,  and 

c)  Assessing  the  utility  of  the  constructs  and  the  features  in  terms  of  addressing 
key  software  development  problems  and  thereby  facilitating  software 
development  tasks. 

Since  any  automation  concept  is  targeted  to  address  one  or  more  specific  problems 
arising  in  the  context  of  software  development,  we  consider  the  utility  assessment  in  the 
context  of  following  major  problems  that  arise  in  development  of  complex  software  based 
systems: 

•  Managing  complexity.  Complexity  of  a  large  software  project  arises  primarily  from  the 
complexity  of  the  problem  and  solution  domain  and  associated  space  of  requirements 
and  design  decisions.  Due  to  the  complexity,  very  few  stakeholders  have  a  complete 
understanding  of  the  system.  Such  global  understanding  is  critical  in  identifying  and 
resolving  conflicts  and  interactions  between  decisions,  developing  a  coherent  and 
integrated  design,  reducing  risks  arising  from  uncertainties,  and  evolving  the  system  as 
requirements  change. 

•  Supporting  coordination.  Most  large-scale  systems  involve  multiple  stakeholder 
communication  and  decision  making.  Such  stakeholder  interactions  may  range  from 
same-time  same-place  interactions  to  different-place  different-time  interactions.  In -all 
such  cases,  due  to  the  dependencies  between  the  decisions,  coordination  is  required  to 
ensure  proper  flow  of  information  to  relevant  parties. 

•  Change  management.  Change  is  an  essential  attribute  of  all  software  projeets.  Changes 
taking  place  in  requirements  and  design  decisions  must  be  propagated  and  their  effects 
analyzed  to  determine  how  existing  decisions  are  affected. 

•  Automation.  In  software  development  there  are  large  numbers  of  routine  tasks  that  are 
well  understood  but  tedious  to  perform.  Automating  routine  tasks  leads  to  improved 
quality  of  the  design  (by  reducing  the  errors  introduced  by  manual  steps)  as  well 
reduction  in  the  development  time.  Moreover  the  automation  of  best  practiees  can 
yield  significant  improvement  in  achieving  desired  quality  goals. 
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For  a  complementary  feature-by-feature  evaluation  of  the  ADM,  see  [Fawcett  et  al., 

1997]. 

N.1.2  ADM  Key  Ideas  and  Usage  Model 

The  key  ideas  underlying  the  ADM  model  are; 

1 .  Complexity  Management  via  abstract  representations  of  requirements  and  design, 
automation  for  process  enactment,  and  consistency  between  work  products  via 
critics.  The  abstract  representations  capture  knowledge  relevant  to  specifie 
concerns.  The  abstract  processes  capture  knowledge  on  the  process  steps, 
preconditions  capturing  dependencies  on  other  steps  and  resources,  and  effect  on 
the  product  representations  [Mi  et  al.,  1990].  Critics  check  for  constraint  violation, 
monitor  dependencies  and  notify  via  creation  of  tasks  that  resolve  such  violations. 

2.  Automation  of  best  practiees.  This  is  done  via  critics  that  encode  transformation 
knowledge  as  well  as  knowledge  on  issues  that  arise  when  best  practices  are  not 
followed  [Johnson  et  al.,  1991]. 

3.  Coordination  support.  The  support  is  provided  via  critics  that  capture  dependency 
knowledge  and  notify  the  stakeholders  (users)  via  updating  the  agenda  of  tasks. 

The  two  fundamental  modes  of  using  ADM  are  i)  Explicit  process-driven  control  —  in 
this  mode  the  software  engineering  activities  are  structured  and  managed  by  a  specified 
process,  which  specifies  the  activities,  the  actors  and  an  ordering  on  the  activities,  ii) 
Independent  control  —  in  this  mode,  the  project  members  act  independently  and  hence  the 
process  remains  implicit.  Our  evaluation  study  was  based  on  a  limited  version  of  ADM  that 
did  not  provide  support  for  the  first  mode. 


N.1.3  Outline 

To  identify  the  ADM  support  features  and  understand  their  usage  in  software 
development  we  first  exercised  ADM  on  two  medium  sized  software  development 
problems  involving  automated  banking  services  and  Automating  gas  station  services. 
Section  N.2  reports  on  the  object  oriented  analysis  (using  UML)  and  usage  models  of 
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ADM  that  resulted  from  such  a  study.  Section  N.3  presents  the  usage  analysis  of  ADM  in 
terms  of  use-cases  and  sequence  diagrams  that  elaborate  the  use-cases.  Section  N.4  asks 
the  questions  on  how  effective  the  support  concepts  and  functional  features  are  for 
improving  software  development  productivity  by  analyzing  them  in  the  context  of  the 
problems  articulated  in  section  N.l.  Section  N.5  provides  our  overall  summary  evaluation 
of  the  ADM  in  terms  of  its  potential  impact  on  software  cost  and  schedule. 

N.2  Object  Oriented  Analysis  &  Modeling  of  ADM  Support  Elements:  ADM  Artifact 
Meta  Model 

The  support  concepts  in  ADM  are  based  on  the  insight  that  the  engineering  of  complex 
software  based  systems  require  creation  and  usage  of  different  models  [Rumbaugh  et  al., 
1991]  that  allows  separation  of  concerns  and  decomposing  the  problem  to  manage 
complexity.  Moreover  the  models  aid  in  expressing  design  decisions  and  visualizing  their 
effects.  The  KBSA/ADM  environment  provides  support  for  capturing  and  relating  three 
distinct  models;  a)  Decision  rationale  model  -  modeling  business  cases,  decisions  and 
rationale  for  them  b)  Conceptual  model  for  modeling  terms  and  requirements  c) 
Specification  model  for  modeling  requirements  specification  and  design. 

In  a  development  activity  the  above  models  may  be  created  in  fragments  via  activity 
sessions.  This  gives  flexibility  in  organizing  one’s  work  and  also  flexibility  in  structunng 
the  model  space.  ADM  recognizes  such  a  need  and  allows  creation  of  sessions  and 
structuring  sessions  based  on  the  model  elements  called  topic  types  that  get  instantiated 
and  manipulated  as  views.  The  structure  of  interactions  wdth  the  ADM  environment 
follows  the  model-view  controller  pattern  [Krasner  et  al.,  1988]  where  a  model  is  defined 
by  a  set  of  topic  instances  and  views  constitute  a  working  view  on  a  topic  instance. 


107 


Figure  N-1:  The  KBSA/ADM  meta-model  showing  the  models  and  views  created  in  a 
software  development  activity  and  managed  by  ADM. 


Figure  N-1  shows  the  conceptual  model  of  ADM  captured  as  an  UML  class  diagram.  As 
shown  in  the  figure,  a  project  consists  of  one  or  more  session  objects,  a  session  consists  of 
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one  or  more  topic  instances  (of  model  stereotype)  and  a  topic  instance  consists  of  one  or 
more  views.  A  topic  in  ADM  is  modeled  as  a  «Model»  stereotype  and  a  view  is 
modeled  as  «View»  stereotype  in  UML. 

The  complexity  of  providing  tools  that  aid  in  capture  and  management  of  the  above 
categories  of  models  (the  topics)  is  addressed  in  ADM  by  a  divide  and  conquer  strategy. 
The  ADM  support  system  is  a  composition  of  the  following  tools: 

•  RASE  -  for  creating  and  managing  the  requirements  model  elements  as  well  as 
discussion  topics, 

•  ALE  -  for  graphical  capture  and  evolving  of  the  object  oriented  specification  models, 
and 

•  IPSE  -  for  graphical  capture,  editing  and  enactment  of  process  plans. 

The  following  subsections  model  the  key  view  specific  representation  constructs  in  ADM 
as  first  class  objects  and  describe  the  operations  on  them  relevant  to  capture  of  the 
knowledge. 

N.2.1  Requirements  Document 

The  requirements  model  is  informally  captured  as  a  set  of  sentences  in  English  and 
represented  in  a  tree  structured  format.  The  tree-structured  format  allows  two  distinct 
views  of  the  requirements  model:  a)  Hyperdocument  view,  and  b)  Outline  view  or 
taxonomy  view.  A  metamodel  of  the  requirements  model  is  shown  in  Figure  N-2.  The 
metamodel  is  represented  as  a  package  consisting  of  two  elements  that  model  the  normal 
outline  view  document  and  the  hyperdocument  view.  The  meta-model  shows  the  key 
operations. 
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Requirements  Document 


Figure  N-2:  The  requirements  document  model  artifact  and  the  views  associated  with  the 
model  formalized  in  UML. 
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N.2.2  Discussion  Artifact 


Figure  N-3  shows  the  discussion  artifact  model  consisting  of  the  root  class  called 
'discussion  node’  that  gets  specialized  by  the  ‘Argument’,  ‘Issue’  'Position',  'Decision', 
'Requirement'  and  'Assumption'  classes.  All  classes  have  two  attributes  -  the  discussion 
element  'name'  and  'description'  for  capturing  the  content  of  the  element.  The  key 
operations  supported  by  each  class  are  for  creating  links  between  the  discussion  nodes  in  a 


Discussion 


Figure  N-3:  The  discussion  model  showing  the  discussion  artifacts  and  their  relationships. 

discussion  fragment  instance  as  well  as  'Create  ObjectLinks  (hyperlinks)  to  other  artifact 
instances. 


N.2.3  Specification  Artifact 


The  specification  artifact  model  (the  specification  package)  in  Figure  N-4  shows  the 
structure  and  behavior  of  the  artifact.  The  structural  elements  in  a  Specification  are  a) 
‘package’  with  attribute  Name  and  methods  ‘Create  Package’  and  ‘Create  Relation’  and  b) 
class  diagram  The  package  ‘Package  Diagram’  contains  class  ‘Class  Diagram’  which  in 
turn  has  various  methods  like  ‘Create  Method’,  Create  Attribute’  etc. 


Specification 


Figure  N-4.  The  specification  model  for  capture  of  the  abstract  design  knowledge  in  terms  of 
packages  and  classes. 
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The  ALE  tool  in  the  ADM  prototype  provides  support  for  package  and  class  diagrams.  The 
package  and  class  representations  supported  in  ALE  are  a  limited  form  of  the  UML 
concept.  A  package  is  used  as  an  abstraction  of  a  group  of  classes.  In  the  ALE  diagrammer, 
lines  between  class  objects  are  used  to  represent  inheritance  relationships.  The  ALE 
diagrammer  also  allows  capture  of  composition  relation  where  a  class  is  an  aggregation  of 
two  or  more  objects. 

N.2.4  Critics 

ADM  provides  expert  knowledge  based  assitance  via  critics.  Critics  encode  design 
knowledge  that  are  used  to  check  for  integrity  of  the  representation  created  by  the  user 
(directly  or  indirectly  via  application  of  tools  such  as  compilers).  For  example,  if  a  class  is 
deleted  and  the  corresponding  Eissociated  relationship  is  not  deleted,  the  ALE  critic  sends  a 
message  to  the  KBS  A  session  manager.  The  session  Manager  then  adds  a  resolution  to  the 
process  plan  that  requires  the  user  to  either  delete  the  dangling  relationship  or  add  the  class 
back  again.  The  following  are  major  types  of  critics  supported  in  ADM: 

•  Content  critic  -  evaluates  the  package  for  its  correctness  (primarily  syntactic  checking). 

•  Task  completion  critic 

•  Cohesion  and  coupling  critic 

ADM  currently  does  not  provide  any  capability  to  develop  new  or  edit  existing  critics. 

N.3  ADM  Use  Case  Analysis 


ADM  can  be  used  to  support  specific  tasks  in  the  software  life  cycle.  A  functional 
evaluation  of  the  ADM  concepts  and  support  tools  can  be  performed  via  use-case  analysis 
[JAC92].  Figure  N-5  shows  the  use-case  diagram  that  captures  the  relevant  usages  of  the 
ADM  system,  their  inter-relationships  and  relationships  with  the  end  actors  (or  users).  The 
following  subsections  elaborate  on  each  of  the  use  cases  and  model  them  using  sequence 
diagrams.  The  sequence  diagram  captures  the  relevant  view  (e.g.  discussion)  specific 
support  element  and  the  operations  performed.  Given  sueh  a  model  that  provides  a 
detailed  view  of  each  use-case,  it  is  then  possible  to  evaluate  how  each  operation  is 
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supported  effectively  as  well  as  the  reduction  in  the  effort  involved  in  performing  the 
specific  task.  We  consider  the  requirements  engineering  and  design  of  an  ATM  for  a  bank 
system  in  describing  the  models.  Moreover  in  describing  the  scenarios  we  consider  actions 
at  the  conceptual  modeling  level  as  opposed  to  specific  menu  choices  and  button  clicks. 


Figure  N-5.  Use  case  diagram  showing  the  possible  usage  of  the  ADM  tool 
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N.3.1  Requirements  Refinement  -  Discussion  Driven 
In  the  initial  phases  of  the  software  development  life  cycle,  the  requirements  identified  in 
the  requirements  document  may  need  to  be  refined  through  discussion  and  design.  Figure 
N-6  shows  the  ADM  artifacts  involved  in  the  requirements  refinement  process  when 
developing  the  requirements  for  the  ATM  bank  example. 
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Figure  N-6:  ADM  artifacts  involved  in  requirements  refinement. 
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The  detailed  scenario  of  the  interaction  between  the  artifacts  is  described  by  the  sequence 
diagram  in  Figure  N-7. 


:User  :  Hyperdoc<<View»  :  Discu5sion«View>> 


1;  Req=Automated 

Banking  ^ 

2;  Export  as  Issue  i 
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e  Expbre  Argument 
- &  Decide - 


5:  capture 
position=ATM 
et  Bank 


8;  Add  refinement:  ! 

ATM  service  i 


7:  Capture  Argumert 
&  Decisbn 


Figure  N-7:  Sequence  diagram  showing  the  artifact  interactions  and  user  actions  in 
requirements  refinement. 


As  can  be  observed  from  the  sequence  diagram,  the  core  (or  minimum)  set  of  steps 
involved  in  the  refinement  activity  consists  of  the  user:  a)  exporting  a  requirements 
document  artifact  as  an  issue,  b)  navigating  the  discussion  graph,  c)  exporting  a  discussion 
artifact  (chosen  position)  as  a  refinement  to  a  requirement  document. 


N.3.2  Requirements  Restructuring 

Discussions  on  requirements  may  create  arguments  and  decisions  that  lead  to  restructuring 
(evolution)  of  the  requirements.  ADM  facilitates  such  as  a  process  by  providing 
representations  and  operations  to  capture  the  in-process  artifacts.  Figure  N-8  shows  the 
ADM  views  created  and  their  relationships  explored  in  such  an  activity. 
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Figure  N-8  :  The  ADM  artifacts  supporting  capture  of  in-process  knowledge  when  doing 
requirements  restructuring. 


The  basic  scenario  involves  the  following  sub-steps: 

•  Capture  the  issues 

•  Mark  the  issues  that  cannot  be  implemented 

•  Navigate  to  the  requirement  document  to  identify  the  requirements  that  raised  these 
issues 

•  Mark  the  requirements  as  Non-Implementables. 

•  Link  the  marked  requirements  to  the  argument  objecting  the  position  in  discussion 
view 

N.3.3  Requirements  Feasibility  Analysis  via  Design 

In  the  initial  stages  of  requirements  decision  making,  feasibility  of  some  of  the 
requirements  decisions  need  to  analyzed  to  avoid  costly  backtracking.  The  requirement 
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feasibility  analysis  can  be  focused  by  the  discussion,  which  identifies  those  elements  in  the 
requirements  whose  feasibility  is  of  concern  to  specific  stakeholders.  Figure  N-9  shows  the 
ADM  artifacts  that  aid  in  capture  of  the  artifacts  considered  during  the  activity. 
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Manage  Accounts: 

-Checking 

-Savings 

Figure  N-9:  The  ADM  artifacts  involved  in  requirements  feasibility  analysis  via  design. 

A  typical  scenario  elaborating  the  steps  involved  in  such  an  activity  is  shown  in  Figure  N- 
10.  The  key  steps  here  are: 

•  Capture  the  Issue  (I)  (whose  body  specify  the  requirement). 

•  Capture  the  position  (of  the  form  “realize  using  position  x”). 

•  Map  requirements  to  specification 

•  Elaborate  the  specification 

•  Map  results  of  specification  modeling  to  discussion 
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N.3.4  Position/Option  Exploration 

In  this  activity,  positions  introduced  in  the  discussion  process  get  analyzed  via 
specification  creation.  ADM  supports  capture  of  the  discussion  elements  the  specification 
elements  involved  in  the  activity  as  shown  in  Figure  N-1 1. 
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Figure  N-11:  The  ADM  artifacts  participating  in  capture  of  knowledge  that  support 
position/option  exploration  via  specification  analysis. 


A  scenario  for  such  an  activity  would  involve: 

•  Create  an  issue 

•  Capture  discussion  on  an  issue  and  the  (multiple)  positions  pertaining  the  issue 

•  Create  package  diagram  for  each  position  and  class  diagram  model  of  the  position 

•  Link  individual  package  to  a  position 

N.3.5  Linking  and  Navigation 

The  Object  linking  capability,  which  provides  the  feature  of  traceability  is  provided  in  the 
KBS  A/ ADM.  The  following  sequence  of  steps  illustrates  the  navigational  capabilities. 

Linking : 

•  Create  any  two  views  such  as  'hyper  document'  and '  discussion' 

•  Select  any  entity  as  source  in  one  view  and  as  target  in  the  other  view 

•  Create  object  link 

Navigation: 

•  Select  one  of  these  views  such  as  'hyper  document' 

•  Click  on  the  entity  which  is  set  as  link 

•  Other  view,  which  is  'discussion'  is  popped  up,  as  it  is  linked  to  the  clicked  entity  of 
the  'hyper  document'  view 

The  navigation  is  bi-directional.  It  can  be  done  from  any  of  the  views  to  the  other  views. 
Figure  N-12  schematically  shows  the  creation  of  the  links  between  an  artifact  in  the 
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discussion  view  (Issue  =  24hrs  banking)  and  an  artifact  in  the  hyper-document  view 
(Requirement  =  necessary  to  have  24hrs  banking). 


Discussion 

Hyper-document 

Create  nocfe: 

-It’s  necessaiy  to  have  24hrs 

-Issue  -  24hrs  banking 

banking  . 

(Linked  as  source) 

(Linked  as  target) 

Figure  N-12  :  Linking  elements  in  the  discussion  view  with  elements  in  the  hyper-document 
view. 


N.4  Evaluation  of  ADM:  Effectiveness  and  Utility 

The  evaluation  of  ADM  was  restricted  only  to  the  tools  for  capture  of  requirements  and 
design  representations.  We  were  unable  to  run  and  exercise  the  process  capture  and 
enactment  tool.  The  key  strategy  in  our  evaluation  effort  was  to  exercise  the  toolset  as  a 
whole  as  opposed  to  just  evaluating  each  tool  independently.  The  basis  for  such  a  strategy 
was  a)  most  of  the  tools  were  independently  developed  outside  of  the  ADM  project  (e.g. 
REMAP  [RD92])  and  hence  have  been  evaluated  in  the  course  of  the  research  performed 
on  the  tool,  b)  scalability  and  applicability  to  engineering  of  complex  software  systems  that 
involve  multiple  stakeholders  require  coping  with  such  concerns  as  complexity 
management,  interoperation  between  the  representations,  coordination,  sharing  of  models 
and  workflow.  We  assumed  that  the  primary  leverage  of  ADM  concepts  and  support  was 
in  providing  such  capabilities  via  integration  and  evolution  of  an  existing  set  of 
components  that  provided  specific  capabilities. 

The  above  evaluation  goals  were  achieved  in  two  steps:  a)  Understanding  the 
representational  constructs  underlying  each  tool  and  the  integrated  usage  of  the  constructs 
to  support  various  software  engineering  activities  -  such  analysis  provided  a  measure  of 
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the  effectiveness  of  the  representational  constructs,  and  b)  Exercising  the  ADM  tool  in 
requirements  engineering,  and  design  of  medium  size  systems  such  as  the  ATM  for  a  bank 
and  automated  gas  pump.  The  objective  of  the  exercise  was  to  evaluate  the  utility  of  ADM 
in  managing  complexity  of  medium  sized  projects.  Below  we  list  the  observations  made 
from  conducting  the  evaluation  study. 

•  Evaluation  of  ADM  framework  and  integration  concepts  independent  of  the  context 
of  Usage.  The  ADM  approach  to  integration  of  components  based  on  the  model-view 
controller  architectural  style  has  several  advantages  and  matches  very  well  to  support 
the  requirements  for  scaleable  distributed  software  engineering.  The  key  observations 
are: 

a)  Management  of  complexity.  The  concept  of  working  in  a  session  characterized 
by  first  class  view  objects  managed  and  controlled  by  view  representation  specific 
tools  (the  IPSE,  the  ALE,  etc.)  makes  it  possible  to  effectively  capture  and  manage 
knowledge  relevant  to  specific  software  development  concerns. 

b)  Flexible  evolution.  The  style  also  allows  flexible  evolution  by  allowing  other 
view  specific  components  to  register  and  make  updates  to  the  model. 

c)  View  integration.  The  concept  of  a  view  in  such  an  approach  is  to  be 
distinguished  from  a  database  view  where  the  view  corresponds  to  a  model  of  a 
query  to  the  database.  The  model  in  the  ADM  is  just  the  composition  (or  union)  of 
the  views.  A  major  problem  in  such  a  multiple  view  driven  software  development  is 
ensuring  global  integrity  across  the  views.  The  concept  of  critics  could  serve  an 
useful  role  here  but  ADM  fails  to  effectively  exploit  such  a  concept. 

d)  Persistence  management  and  non-intrusive  model  update.  The  use  of  the 

object  persistence  feature  provided  by  the  object-store  management  system  and  the 
concept  of  change  in  view  to  be  propagated  to  the  model  is  very  effective  in  non- 
obtrusive  propagation  of  change  in  the  view  to  change  in  the  model.  The  user  does 
not  have  to  take  extra  steps  to  save  changes  to  the  model. 
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e)  Asynchronous  collaboration.  The  nature  of  collaboration  supported  in  ADM 
is  primarily  process  driven.  A  major  weakness  of  ADM  is  that  it  does  not  provide 
means  for  product  representation  driven  asynchronous  collaboration.  The  weakness 
can  be  addressed  by  providing  stronger  support  for  critics  that  add  specific 
collaboration  goals  based  on  the  product  models  created  or  changed  asynchronously 
by  the  individual  stakeholders. 

•  Evaluation  of  ADM  tools:  Editors  for  Knowledge  Capture,  Linking  and 
Transformations.  The  ADM  concepts  and  framework  can  be  understood  and  evaluated 
from  the  viewpoint  of  software  design  and  development  as  knowledge-based 
debugging.  The  project  deliverables  are  generated  via  model  editors.  In  such  a 
conceptualization,  the  evaluation  of  ADM  is  based  on  evaluating  the  high-level  editors 
for  capture,  linking,  transformation  and  management  of  models  of  the  product 
manipulated  in  the  early  phases  of  the  software  life  cycle.  The  utility  of  the  individual 
view  specific  captured  models  can  be  seen  from  the  ADM  use-case  analysis  (in  section 
3)  that  shows  how  changes  and  refinements  in  one  model  can  be  used  to  focus  changes 
in  another  view.  The  key  evaluation  results  are: 

f)  Hyperdocumentation.  The  major  goal  of  the  hyperdocument  editor  is  to 
provide  constructs  for  capture  of  loosely  structured  documents,  with  links  that 
enable  the  user  to  navigate  to  various  other  project  deliverables.  The  ADM 
enviromnent  provides  a  limited  editor  in  terms  of  kinds  of  hyperdocuments  and 
their  structuring.  The  linking  capability  provided  by  ADM  is  very  strong.  Given  the 
current  progress  and  acceptance  of  standards  for  hypertext  based  on  HTML  (and 
XML),  a  major  concern  is  compatibility  of  ADM  hyperdocument  representation 
with  such  standards. 

g)  Rationale  Capture  -  documentation.  The  discussion  view  (based  on  REMAP 
[Ramesh  et  al.,  1992])  provides  an  effective  means  to  graphically  capture  rationale 
fragments.  The  graphical  approach  makes  use  of  icons  and  is  very  easy  to  use.  One 
major  problem  is  the  complexity  of  book-keeping  of  such  rationale  structures 
resulting  from  the  expressivity  of  the  rationale  representation  (  too  many  node 
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types  and  relations).  Developing  automated  support  for  propagation  of  change  and 
dependency  structure  analysis  based  on  such  representations  and  that  scales-up  is 
very  difficult. 

h)  Design  Representation.  The  goal  of  the  design  representation  is  to  capture 
design  specifications  that  can  be  automatically  transformed  into  C-h-  code.  This  is  a 
very  difficult  task.  The  ALE  representations  used  to  capture  specifications  is  very 
limited  and  supports  generation  of  only  C-H-  header  files.  Current  technologies 
(Rational  Rose,  Visual  Basic,  Visual  C-H-)  have  made  significant  progress  in  code 
generation  from  high-level  object  models  and  interface  specifications.  The 
challenge  is  providing  automated  assurance  of  global  requirements  or  properties 
without  compromising  scalability. 

•  Evaluation  of  ADM  tools:  For  analysis.  A  major  weakness  of  the  current  ADM 
support  framework  is  the  lack  of  tools  for  analysis  of  the  software  views  and  models 
being  captured  in  the  representations.  There  is  very  little  analysis  via  the  use  of  pre¬ 
defined  set  of  critics. 

N.5  Summary  Evaluation  of  the  ADM 

1 .  The  ADM  environment  fi-amework  has  good  technical  concepts  (model- 
view  controller  architecture;  process-driven  environment;  persistent  object 
base). 

2.  These  concepts  have  several  critical  issues  regarding  the  feasibility  of 
their  use  on  large,  complex  projects  (scalability;  overconstraining  people- 
collaboration  processes). 

3.  The  ADM  was  not  fully-enough  implemented  to  resolve  these  issues. 

4.  Much  of  the  ADM  has  been  overtaken  by  commercial  technology  (e.g., 
Rational  Rose). 

5.  The  ADM  has  some  good  concepts  such  as  the  use  of  critics  for 
software  project  decision  assistance  or  conceptual  debugging. 
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6.  For  the  foreseeable  fiiture,  KBSA  technology  will  have  more  impact  on 

software  project  costs  and  schedules  if  pursued  in  terms  of  specialized  tool 
enhancements  of  commercial  environments  (e.g.,  domain-specific  application 
generators;  critics  or  software  project  decision  aids),  rather  than  in  terms  of 
alternative  environments. 
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Appendix: 

Screen  shots  of  the  usage  of  ADM  in  the  ATM  banking  example. 


O.  Appendix  5.  Technology  Impact  Analysis  Tool 


Technology  Impact  Analysis  Tool 


A.  Winsor  Brown 
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0.1  Tool  Overview 


A  multi-sheet  Excel  Workbook  has  been  developed  to  show  the  impacts  of  the  COCOMO II  and 
CORADMO  drivers  projected  over  time  and  technology-type  on  a  selected  domain's  typically 
sized  application.  This  spread  sheet  model  is  named  "Technology  Impact  Analyzer"  or  TIA  for 
short  and  has  the  file  name  TIA.xls.  The  sheets  include  an  overview  and  sheets  for  the 
COCOMO-II.1998  ,  COSSEMO  and  CORADMO  drivers,  data  and  their  impacts. 


The  overview  sheet  includes  abbreviations  and  descriptions  of  the  other  sheets  on  the  first  page. 
Figure  1 .  _  _ _ _ _ . 


I  Techonologji  Impact  Analyzer  Abbreviations  .  . . 

CD=  Commercial  (echnologa  and  DoD  general  practice  :  Cl|=  CoCoMo  ll-1998 

KBSA=  Knowledge  Based  Software  Assistant' . .  SF=  Scale  Factor  EM=  Effort  Multiplier 

KG=  KBS  A  Applications  Generators,  including  KB  domain  engineering  (*CD)  .  CoRADMo  (schedule  6t  effort) 

KD=  KBSA  Project  Decision  Support  (SE  decision  assistant  concept)  (.CD)  . ^  SM=  Schedule  Multiplier 

K=  BothKG  &KD  ; . ; . .  . .  . .  . . . . 

Es  EDCS  or  Euolutionars  Deiiueri)  of  Comple*  Software  Sijsetms  . .  M=  Months 

:  EK=  both  EDCS  6t  KBSA  (KG  «c  KD)  . I . . a  Fulltime  Software  Personnel 

EHART=  Embedded,  High  Assurance,  Fleal  Time  [baseline  application  domain)  SSE=  Staged  Schedule  and  Effort  ? 

l=lncepstion  .  Eg  Elaboration  i  C=  Construction 


The  Techonologi)  Impact  Analt)zer  Workbook  has  several  worksheets  covering  ;  .  . 

Technoloi)  Impact  Analyzer  Overview  Sheet  ("TIA"  tab):  This  sheet  with  . .  ; 

1.  Abbreviations  and  worksheet  overviews . J . .  i  . .  . 

2.  COCOMOII- 1998  Calibration  values  and  ranges  j .  i  . | .  . 

COCOMOII-1998  Scale  Factor  s  Effort  Multiplier  Drivers . .  .  . .  .  ^ 

COCOMOII- 1998  Scaie  Factor  8c  Effort  Multiplier  Drivers  projected  over  time  ("Cll  Drivers"  tab)  . . .  « 

Individual  parameters  displayed  with  default  and  newfcurrent  numeric  values,  and  graph  of  current  values,  . i . 

COCOMOII- 1998  Scale  Factor  8c  Effort  Multiplier  Data  ("Cll  Data"  tab) . . 

1.  Parameters  organized  in  a  compact,  single  page  for  review,  along  with  schedule  8c  effort  calculation.  . | 

2.  Calculates  effort  according  to  the  COCOMOII-98  rules  and  schedule  according  COSSEMO  rules 

(different  schedule  formulas  for  three  ranges  of  rnonths-0  to  16;  1 6  to  64;  and  64  and  up).  . . j 

;  COCOMOII- 1 998  Effort  and  Schedule  Impact  ("ai  Impact"  tab)  . . ; . 

Displays  the  Effort  6c  Scheduje  impacts  that  result  from  the  driver  values’  change  over  time. . . 

COSSEMO:  Stage  (Inception,  Elaboration  and  Construction)  percentage  distribution  of  Schedule  and  Effort  ("SSE  K"  tab) 

1.  Input  of  inception,  elaboration  and  constrution  stages' schedule  and  effort  percentages  ; . . ; 

2,  Chart  of  distribution  of  schedule  and  effort  impacts  on  the  current  COCOMO  II  calculations  . 

CORADMO:  Schedule  and  Effort  Multipliers  Projected  Over  Time  for  KBSA  Evaluator . . . 

CoRADMo  Drivers  projected  over  time  ("RAD  Drivers"  tab)  1 . .  . 

Individual  parameters  displayed  with  default  and  newfcurrent  numeric  values,  and  graph  of  current  values. 

CoRADMo  Drivers  projected  over  time  ("RAD  Data"  tab) . .  . . ; . 

1.  Parameters  Organized  in  compact  single  page  for  review  .  . 

2.  Calculates  effort,  schedule  6i  FSP  according  CORADMO  rules  after  distribution  of  effort  &  schedule  per  COSSEMO  rules. 

CoRADMo  Schedule  and  Effort  Multipliers  Impact  ("RAD  Impact"  jab)  _  ; _ _ . ;  _ _ : . i  . . . 

FinarResults -==>  :  Displays  the  Effort,  Schedule  and  FSP  impacts  that  result  from  the  driver  values'  change  over  time ' _ ^--r— r-- - 

„  ^  /^^Tii^Drh^rs/R^afca  /  RADlrrpact  ,^llj 


Figure  1.  TIA  Abbreviations  and  Sheet  Descriptions 
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On  the  second  page  it  has  the  COCOMO-II.1998  calibration  values  and  ranges  for  reference. 
Figure  2. 


The  following  COCOMOI1 1938  Calibration  data  is  Inciude  to  assist  the  user  in  determining 
appropriate  ranges  and  increments  for  parameters  in  the  KBSA  Evaluator. 
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Figure  2.  COCOMO-II.1998  Baseline  Values 


0.1.1  COCOMO-II  Drivers,  Calculations  and  Impacts 

There  are  three  sheets  in  this  grouping.  The  first,  "CII  Drivers",  has  the  current  projected  scale 
factors  and  effort  multipliers  drivers  over  time  and  allows  for  changing  the  default  values  to  their 
new  values.  The  second,  "CII  Data",  aggregates  the  driver  data  and  does  the  COCOMO  II 
calculations.  The  third,  "CII  Impact",  has  graphs  showing  the  effort  and  schedule  impact  of  the 
COCOMO-II.1998  drivers  projected  over  time. 

0.1 .2  CoSSEMo  Schedule  and  Effort  Percentage  Distributions  per  Stage 

This  sheet,  “SSE  %”,  allows  the  input  of  percentage  distributions  of  effort  and  schedule  to  the 
various  stages.  Inception,  Elaboration,  and  Construction,  as  required  for  the  COCOMO  II  Staged 


Schedule  and  Effort  Model  (COSSEMO).  The  impact  of  these  distributions  on  the 
COCOMO-IL1998  baseline  results  is  shown  in  the  chart  at  the  end  of  the  worksheet. 

0.1.3  CORADMO  Drivers,  Calculations  and  Impacts 

Like  the  COCOMO-II.1998  sheets,  there  are  three  sheets  in  this  grouping.  The  first,  "RAD 
Drivers",  shows  the  new  or  default  projected  drivers  over  time.  The  second,  "RAD  Data",^ 
aggregates  the  driver  data  and  does  the  CoRADMo  calculations.  The  third,  "RAD  Impact",  has 
graphs  showing  the  resulting  impacts  of  the  CoRADMo  drivers  projected  over  time  when 
applied  to  the  corresponding  COCOMO-II.1998  results  with  the  COCOMO  drivers  projected 
over  time.  At  the  end  of  the  page  of  the  "RAD  Data"  sheet  are  the  summary  calculations  for 
totals  of  schedule  and  effort  across  stages  allowing  comparison  with  the  results  of 
COCOMO-II.1998. 

0.1.4  Technical  Impact  Final  Results 

At  the  end  of  the  "RAD  Impact"  worksheet,  following  the  nine  RAD  impacts  by  stage  charts,  are 
the  summary  charts  for  effort  and  schedule  by  technology  over  time  that  result  from  the 
COCOMO-II.1998  and  CORADMO  driver  changes  over  time.  The  effort  and  schedule  results 
are  generated  by  adding  the  effort  or  schedule,  respectively,  for  either  all  three  stages  or  just  for 
the  Elaboration  and  Construction  stages. 

0.2  CoCoMo  II  Drivers,  Calculation  and  Display  of  Impacts 

The  three  sheets  in  this  grouping  show  the  driver  data,  COCOMO-II.1998  calculations,  and  the 
impacts  of  the  projected  drivers  over  time  and  technology. 

0.2. 1  CII  Drivers  -  Display,  Modification  and  Rationale 

"CII  Drivers"  shows  all  of  our  assessed  values  for  each  of  the  scale  factor  or  effort  multiplier 
drivers,  projected  over  time  and  technology,  and  our  rationale.  Each  page  of  this  worksheet  has 
the  current  projected  COCOMO-II.1998  drivers,  both  scale  factors  and  effort  multipliers,  over 
time  and  allows  for  changing  the  default  values  to  their  new  values.  The  rationales  for  the 
default  settings  of  the  drivers  eire  included;  they  should  be  modified  when  “new  values  are 
provided.  Figure  3  shows  the  scale  factor  PREC’s  information. 
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PREC:  Precedentedness  ■ 

Driver  Baselirre  CD@»8:D(g).1i  KG@«8<G@«1!  K(g>»8|K@»15  E(g»»S  E(g>«15  EK(g>.8  EK@.15 

PREC  default  3.06  2.80  2.50  2.50  2.00  2.80  2.50  iiol  Eoo  2.50  2.00  2.50  2.00 


- CD-B-KG -$-KD-»«-K  — 1— E-o— EK  A  SF 

CD:  Some  gains  due  to  better  general  understanding  of  EHART  domains,  but  not  large  : 
Solid  gains  due  to  stronger  domain  understanding  and  technology,  but  offset  by  continuing 
need  for  more  advanced  systems 

KD:  No  additional  domain  gains  oyer  CD_ . . i _ i_ _ J _ . . j _ f _  ■ 

K:  Same  as  KG 


E:  No  additional  domain  gains  over  KG  < 

EK:  Same  as  E  and  K 

. ;■■■  '  . ; . ^ . i 

. r  '  . ! . '  '  ' 

. . . ^ . ; . ; . ^ . ’ . { . ^ . - . ^ . } . i . j . ! . j . : 

Figure  3.  PREC’s  Driver  Entry,  Modiflcation  and  Display 

The  default  and  current  values  of  the  driver,  projected  over  time  and  technology,  are  shown  in  a 
small  table  above  the  chart  of  the  current  values.  The  last  row  of  this  table  accepts  the  input  of 
new  values  of  the  driver,  projected  over  time  and  technology.  The  chart  below  the  table  shows 
the  driver’s  current  values  over  time  for  each  technology  combination.  The  data  points  on  this 
graph  change  when  new  values  are  entered. 

Since  each  value  of  a  driver  should  have  a  rationale,  the  rationales  for  the  default  values  (our 
assessed  values)  are  shown  below  the  chart.  The  area  below  the  rationales  for  the  default  values 
allows  the  input  of  additional  or  modified  rationales. 


0.2.2  CoCoMo  II  Calculations 


"CII  Data"  has  the  current  assessed  COCOMO-II.1998  drivers,  both  scale  factors  and  effort 
multipliers,  organized  in  a  compact,  single  page  sheet  along  with  the  calculations  of  the 
COCOMO  II  effort  and  schedule.  The  calculations  use  the  COCOMO-II.1998  model  equations 
for  effort  and  schedule,  and  then  applies  the  COSSEMO  equations  for  schedule  (different 
schedule  formulas  for  three  ranges  of  person-months  of  effort:  0  to  16;  16  to  64;  and  64  and  up). 
Each  column  of  the  table  performs  the  full  set  of  COCOMO-II  calculations  for  a  particular  year 
and  technology-type  combination.  The  worksheet  is  shown  in  Figure  4. 
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Tech  Impact  Analyzer:  COCOMOII-1998  Scale  Factors  &  Effort  Multipliers  --  Now,  +8  &  +15  years 

[COCOMO  II  data  (from  COCOMO  II  Drivers)  and  calculations  _ 
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Figure  4.  CII  Data  Worksheet 
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In  the  sheet  the  following  non-driver  abbreviations,  in  their  order  of  appearance,  are  used. 


Abbreviatio 

n 

Meaning 

Abbreviation 

Meaning 

X 

Sum  of  the  scale  factors 

CII_PM 

COCOMO-II.1998  effort 

B 

The  exponent  for  effort  calculation 

CII_PMnoSCED 

COCOMO-II.1998  effort  without  SCED 

n 

The  product  of  the  effort  multipliers 

CII_PM  Orig. 

COCOMO-II.1998  effort  using  default 
drivers 

rinoSCED 

Effort  multiplier’s  product  without  SCED 

CII_M  Orig. 

COCOMO-II.1998  schedule  [Original] 

SCED% 

The  schedule  compression  percentage. 

CII_Mof64 

COCOMO-II.1998  schedule  at  64  PM 

SIZE  Orig. 

The  original  (default)  SIZE  value 

SSEMo_M 

COSSEMO  schedule  in  months 

SIZE 

The  current  SIZE  value 

SSEMo_M  Orig. 

COSSEMO  schedule  using  default  drivers 

0.2.3  COCOMOII-1998  Effort  and  Schedule  Impacts 


This  work  sheet  displays  the  Effort  &  Schedule  impacts  that  result  from  the  driver  values'  change 
over  time  and  technology.  The  impacts  are  shown  in  both  tabular  and  chart  form,  with  the  chart 
always  reflecting  the  “current”  values  of  the  drivers.  An  example  is  shown  in  Figure  5. 
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65.8 
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175.7 
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108.8 
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85.7 

16.4 

66.7 

10.9] 

Figure  5.  COCOMO-II.1998  based  Development  Effort  Impact  Example 


The  table  above  these  charts  shows  the  calculated  results  based  on  the  default  driver’s  values  and 
the  updated  values  based  on  the  “new”  values  of  the  drivers.  Where  there  are  multiple 
calculations  that  might  provide  useful  information,  those  intermediate  results  are  also  shown,  as 
in  Figure  6. 
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Figure  6.  COCOMO-II.1998  based  Development  Schedule  Impact  Example 


Here,  both  the  original  COCOMO-II.1998  set  of  calculations  and  the  COSSEMO-based  set  of 
calculations  are  shown.  Again,  the  final  row’s  values  will  contain  the  results  based  on  the 
“current”  driver  values,  and  thus  may  have  changes  anytime  there  is  input  in  the  “new”  row  of 
the  drivers. 

0.3  COSSEMO  Distribution  of  Schedule  and  Effort  per  Stage 

There  are  two  parts  to  this  worksheet:  1)  Input  of  inception,  elaboration  and  construction  stages' 
schedule  and  effort  percentages;  and  2)  Chart  of  distribution  of  schedule  and  effort  impacts  on 
the  current  COCOMO II  calculations. 

Input  of  schedule  and  effort  percentage  distributions  per  stage.  Inception,  Elaboration,  and 
Construction,  is  required  for  the  COCOMO  II  Staged  Schedule  and  Effort  Model  (COSSEMO). 
To  help  visualize  these  distributions,  their  impact  on  the  COCOMO-II.1998  lOOK  EHART 
baseline  is  displayed  in  the  chart  at  the  end  of  the  worksheet.  Figure  8  shows  the  entire  content 
of  this  worksheet. 
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staged  Schedule  and  Effort  Percentages 
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40 

Con  SoA 
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The  following  chart  shows  the  distribution  of  effort  and  scheduie  on  the  default  baseline  CoCoMo  il  vaiues, 
it  is  important  because  the  RAD-driver  muitipliers  have  different  effects  on  different  stages. 
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Figure  7.  Staged  Scheduie  and  Effort  Distribution. 


The  values  of  the  Inception  and  Elaboration  percentages  for  schedule  and  effort  are  adjusted  by 
clicking  on  the  up/down  arrows  (spinners)  shown  to  the  right  of  their  values.  The  current  values 
are  displayed  in  bold,  along  with  the  corresponding  calculated  values  for  the  Construction  stage. 
The  default  values  for  all  the  percentages  are  shown  in  italics. 

The  chart  that  follows  the  input  area  shows  the  impact  of  the  distributions  on  the  calculated 
baseline  results.  Since  COCOMO-II.1998  only  calculates  the  effort  and  schedule  for  the 
Elaboration  plus  Construction  stage,  the  corresponding  Fulltime  Software  Personnel  (FSP;  AKA 
“Persons”),  labeled  CU  P,  is  shown  only  for  that  duration. 
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0.4  CORADMO  Drivers,  Data  and  Impacts 

The  three  sheets  in  this  grouping  show  the  driver  data,  CORADMO  calculations,  and  the  impacts 
of  the  projected  drivers  over  time  and  technology. 

0.4.1  CORADMO  Drivers  -  Display,  Modification  and  Rationale 

"RAD  Drivers"  has  our  assessed  values  for  each  of  the  relevant  CORADMO  schedule  and  effort 
multipliers  projected  over  time  and  our  rationale.  It  also  allows  the  input  of  new  values  and 
additional  or  modified  rationales.  A  graph  of  the  current  values  of  each  driver  projected  over 
time  and  technology  is  included;  the  data  points  on  this  graph  change  when  new  values  are 
entered. 

There  are  five  CORADMO  drivers  (RVHL,  DPRS,  CLAB,  RESL  and  PROS); 

1 .  RVHL:  Reuse  and  Very  High  Level  Language 

2.  DPRS:  Development  Process  Reengineering  &  Streamlining 

3.  CLAB:  Collaboration  Efficiency 

4.  RESL:  Architecture/Risk  Resolution 

5.  PPOS:  Prepositioning  Assets 

With  five  CORADMO  drivers,  three  stages  (Inception,  Elaboration  and  Construction),  and  two 
multipliers  (effort  and  schedule;  two  of  the  three  variables  in  “Person  Months  =  Persons  * 
Months”,  or  PM=P*M,  equation),  there  are  30  different  driver  possibilities.  How  ever,  there  are 
several  situations  with  reduce  the  actual  numbers  of  drivers  in  the  Technical  Impact  Analyzer. 
The  number  of  persons  is  held  constant  for  RVHL,  DPRS,  CLAB  and  RESL,  and  therefore  the 
drivers  for  effort  and  schedule  have  the  same  value.  The  impact  of  RVHL  on  construction  is 
handled  by/in  the  reuse  model  of  regular  COCOMO-IL1998.  The  impact  of  DPRS  is  assumed  to 
be  the  same  for  Elaboration  and  Construction.  And,  while  PPOS  has  different  multipliers  for 
effort  and  schedule,  the  same  values  are  used  for  all  three  stages.  Thus  the  number  of  drivers  is 
reduced  to  ten  fi-om  thirty,  although  an  eleventh  chart  is  included  in  this  worksheet  to  show  the 
effect  of  the  PPOS  drivers  on  the  number  of  personnel. 

"RAD  Drivers"  shows  all  of  our  assessed  values  for  the  significant  CORADMO  drivers  , 
projected  over  time  and  technology,  and  our  rationale.  Each  page  of  this  worksheet,  vvdth  the 
exception  of  the  last,  has  the  current  projected  CORADMO  drivers,  over  time  and  allows  for 
changing  the  default  values  to  their  new  values  (the  exception  is  for  PPOS’s  ESP  driver  which  is 
a  derived  value).  The  rationales  for  the  default  settings  of  the  drivers  are  included;  they  should 
be  modified  when  “new”  values  are  provided.  Figure  9  shows  RVHL’s  Inception-Schedule 
Multiplier  Driver  Information. 
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Schedule  RVHL:  Reuse  and  Verv  High  Level  Language  Inception; 


0.85  0.89  0.93  0.97  1.01  1.05 


;  ;  I  ;  RVHL  Projection  Rationales  |  :  !  1 

Baseline;  Relatively  low  current  capability  and  experience  in  EHART  domain  (standard  3GL  module  reuse) 
„  As  indicated  under  SIZE  in  the  Effort  impact  analysis,  commercial  technology  and  DoD  EHART 

domain  initiatives  will  provide  some  but  not  much  improvement  over  standard  3GL  module  reuse  | 
KD:  ;  Some  gains  over  CD  via  domain  oriented  reuse  asset  iderrtif ication  and  decision  support ;  i 

KG:  Some  gains  over  CD  via  domain  orient^  prototype  applications  ^neration  |  j 

K;  Complemerttary  gains  from  KD  and  KG  ;  !  1  j  J  ;  i  i  i 


4.  i 


Significant  gains  over  CD  via  domain  architecture  technology  and  associated  prototype  applications  generation 
Some  complemen*  any  gains  from  E  and  K  i  i  i  i  I  ;  ;  I  ?  i 


NOTE  :  RVHL  effects  in  construction  accounted  for  with  regular  COCOMOII  effort  adjustment 


Figures.  RVHL’s  Inception  Stage  Schedule  Multiplier  Driver  Information 


The  default  and  current  values  of  the  driver,  projected  over  time  and  technology,  are  shown  in  a 
small  table  above  the  chart  of  the  current  values.  The  last  row  of  this  table  accepts  the  input  of 
new  values  of  the  driver,  projected  over  time  and  technology.  The  chart  below  the  table  shows 
the  driver’s  values  over  time  for  each  technology  combination. 

Since  each  value  of  a  driver  should  have  a  rationale,  the  rationales  for  the  default  values  (our 
assessed  values)  are  shown  below  the  chart. 

0.4.2  CORADMO  Calculations 


"RAD  Data"  aggregates  the  CORADMO  drivers,  both  schedule  and  effort  multipliers.  They  are 
organized  in  a  compact,  single  page  sheet  along  with  the  calculations  of  the  CORADMO  effort 
and  schedule.  The  calculations  use  the  CORADMO  model  equations  to  distribute  schedule  and 
effort  based  on  the  selected  percentage  allocations  and  the  schedule  or  effort  multiplier  driver 
ratings.  Each  Person-Month  (PM)  &  Month  (M)  pair  of  data  columns  of  the  table  performs  the 
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full  set  of  CORADMO  calculations,  including  the  derivable  Personnel  (P)  values,  for  a  particular 
year  and  technology-type  combination. 

At  the  end  of  the  page  of  the  "RAD  Data"  worksheet  are  the  summary  calculations  for  totals  of 
schedule  and  effort  across  stages  allowing  comparison  with  the  results  of  COCOMO-II.1998. 
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Figure  9.  RAD  Data  Worksheet 
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In  the  sheet,  the  following  additional  non-driver  abbreviations,  in  their  order  of  appearance,  are 
used. 


Abbreviation 

Meaning 

n 

The  product  of  the  five  RAD  drivers  above. 

Baseline  I  (or 
Eor  C) 

The  COCOMO-II-1998  calculated  value  after  applying  the  Staged  Schedule  and  Effort 
percentage  distribution  for  Inception,  Elaboration  or  Construction,  respectively. 

New  I 
(or  E  or  C) 

The  new  value,  i.e.  after  applying  the  RAD  drivers,  for  Inception,  Elaboration  or 
Construction,  respectively. 

P(New  I)  (or  E 
orC) 

The  number  of  Fulltime  Software  Personnel  corresponding  to  the  new  values  for 

Inception,  Elaboration  or  Construction,  respectively. 

New  I+E+C 

The  new  value  (PM  or  M,  depending  on  the  column),  i.e.  after  applying  the  RAD  drivers, 
combined  for  Inception,  Elaboration  and  Construction 

P(new  I+E+C) 

The  number  of  Fulltime  Software  Personnel  corresponding  to  the  new  values  for 

Inception,  Elaboration  or  Construction. 

Baseline 

PM/M 

Provided  for  reference  purposes,  it  shows  the  “baseline”  (the  sum  for  all  stages  of  the 
COCOMO-II-1998  calculated  value  after  applying  the  Staged  Schedule  and  Effort 
percentage  distributions)  Fulltime  Software  Personnel. 

New  E+C 

The  new  value  (PM  or  M,  depending  on  the  colunrm)  for  the  combination  of  the 

Elaboration  and  Construction  stages.  This  corresponds  to  the  stages  over  which 
COCOMO-II.  1998  calculations  apply. 

P(new  E+C) 

The  new  Fulltime  Software  Personnel  (FSP  and  P)  calculations  for  the  combination  of 
the  Elaboration  and  Construction  stages. 

CII-OT(I+EC) 

COCOMO-II.  1998  values,  applying  the  projected  drivers  over  time  and  technology,  for 
the  same  stages  as  the  summed  CORADMO  calculations;  i.e.  the  sum  for  all  stages  of 
the  COCOMO-II-1998  calculated  values  after  applying  the  Staged  Schedule  and  Effort 
percentage  distributions.  Since  COCOMO-II.  1998  does  NOT  include  an  Inception  stage, 
the  additional  percentage  from  the  SSE  distribution  is  used.  Provided  for  reference 
purposes,  it  shows  a  “baseline”  prior  to  apply  the  RAD  drivers. 

Sum( 

New(I+E+C)) 

Repeated  values,  equivalent  to  New  I+E+C,  for  the  new  value  (PM  or  M,  depending  on 
the  column),  i.e.  after  applying  the  RAD  drivers,  combined  for  Inception,  Elaboration 
and  Construction. 

C1I-0T(E+C) 

COCOMO-II.  1998  values,  applying  the  projected  drivers  over  time  and  technology,  for 
the  its  covered  stages;  i.e.  for  the  Elaboration  and  Construction.  Provided  for  reference 
purposes,  it  shows  a  “baseline”  prior  to  apply  the  RAD  drivers. 

Sum( 

New(E+C)) 

The  new  value  (PM  or  M,  depending  on  the  column)  for  the  combination  of  the 
Elaboration  and  Construction  stages.  This  corresponds  to  the  stages  over  which 
COCOMO-II.  1998  calculations  apply.  Provided  to  ease  comparison  with  row  above. 
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0.4.3  CoRADMo 


0.4.4  Effort  and  Schedule  Impacts 

"RAD  Impact"  has  graphs  showing  the  effort,  schedule  and  Full-time  Software  Personnel  (FSP) 
impacts  of  the  entered  CORADMO  drivers  projected  over  time.  Impacts  on  all  three  variables 
are  shown  for  each  stage:  Inception  (I),  Elaboration  (E),  and  Construction  (C).  The  CORADMO 
drivers  impact  both  effort  and  schedule,  often  to  the  same  extent.  The  third  variable’s  (FSP) 
values  are  then  simply  the  result  of  dividing  effort  (in  person  months)  of  a  stage  by  its  duration 
(in  months). 

Following  the  RAD  impact  per  stage  charts  are  charts  showing  of  the  totals  of  schedule  and 
effort  across  stages.  These  represent  the  final  results  of  the  Technology  Impact  Analyzer.  There 
are  also  charts  comparing  the  results  of  both  COCOMO-II.1998  and  overall  results.  The  data  for 
the  summary  charts  showing  totals  of  schedule  and  effort  across  stages  is  on  at  the  end  of  the 
page  of  "RAD  Data". 

0.4.4. 1  CORADMO  Effort  and  Schedule  Impacts  per  stage 

The  first  three  pages  of  this  work  sheet  display  the  effort,  schedule  or  personnel  impacts  for  each 
stage  that  result  from  the  drivers  values'  change  over  time  and  technology.  The  impacts  are 
shown  in  both  tabular  and  chart  form,  with  the  chart  always  reflecting  the  “current”  values  of  the 
drivers.  An  example  is  shown  in  Figure  10. 
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The  table  above  each  of  the  charts  shows  the  calculated  results  based  on  the  COCOMOII 
calculations  with  the  Staged  Schedule  and  Effort  (SSE)  percentages  applied.  The  “Results” 
row’s  values  will  contain  the  results  based  on  the  “current”  driver  values,  and  thus  may  have 
changes  anytime  there  is  input  in  the  “new”  row  of  the  drivers.  A  single  stage  example  is  shown, 

as  in  Figure  11. 
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Figure  11.  Combined  COCOMO  &  CORADMO  Impact  on  Effort  for  Inception 


The  remaining  pages  in  the  worksheet  contain  the  summary  results  of  the  entire  KBS  A 
Technology  Impact  Evaluator.  They  are  described  in  the  next  section. 

0.5  Final  Results:  Technology  Impacts  Estimates 

At  the  end  of  the  "RAD  Impact"  worksheet,  following  the  nine  RAD  impacts  by  stage  charts,  are 
the  summary  charts  for  effort  and  schedule  by  technology  over  time  that  result  from  the 
COCOMO-II.1998  and  CORADMO  driver  changes  over  time.  The  “new/current”  data  for  the 
summary  charts  is  actually  shown  at  the  end  of  the  "RAD  Data"  sheet. 

There  are  three  different  types  of  charts: 

1 .  Overall  (effort  or  schedule  for  all  three  stages  or  just  for  development  (elaboration  plus 
construction),  with  some  of  these  having  alternative  axes  layouts; 

2.  COCOMO-IL1998  compared  to  CORADMO  (final)  results,  with  some  of  these  charts 
showing  only  the  major  technology  groupings  (CD,  K  and  EK); 

3.  Final  results  of  default  driver  settings  compared  to  new/current  driver  settings’  results. 


The  list  of  all  the  charts  corresponding  to  final  results  is  shown  below 


Number 

Title 

1. 

CORADMO  Total  Effort  (effort  on  x  axis) 

2. 

CORADMO  Total  Effort  (years  on  x  axis) 

3. 

CORADMO  Total  Effort  (only  for  CD,  K  and  EK) 

4. 

CORADMO  Development  (E+C)  Effort  with  CoCoMo  II  Development  (E+C)  Eftort 

5. 

CORADMO  Development  (E+C)  Effort  with  CoCoMo  II  Development  (E+C)  Effort 
(onlv  for  CD,  K  and  EK) 

6. 

CORADMO  Total  Schedule  (schedule  on  x  axis) 

7. 

CoRADMo  Development  (E+C)  Schedule  with  CoCoMo  II  Development  (E+C) 
Schedule(only  for  CD,  K  and  EK) 

8. 

CoRADMo  Development  (E+C)  Schedule  with  CoCoMo  II  Development  (E+C)  Schedule 

9. 

New/Current  CORADMO  Total  (I+E+C)  Effort  with  Default  CORADMO  Total  (I+E+C) 
Effort 

10. 

New/Current  CoRADMo  Total  (I+E+C)  Schedule  with  Default  CoRADMo  Total  (I+E+C) 
Schedule 

0.5.1  Total  Effort 

The  effort  and  schedule  results  are  generated  by  adding  the  effort  or  schedule,  respectively,  for 
all  three  stages.  Figure  12  shows  the  total  effort  after  applying  the  Staged  Schedule  and  Effort 
distribution  percentages,  and  the  COCOMO-II.1998  and  CORADMO  drivers 
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Figure  12.  Total  Effort  after  applying  both  COCOMO-II.1998  &  CORADMO  Drivers 


In  this  part  of  the  worksheet,  the  table  above  the  charts  shows  the  calculated  results  based  oh  the 
updated  values.  The  “updated  values”  are  those  based  on  the  “current”  (“default”  otherwise 
“new”  if  modified)  values  of  both  the  COCOMO-II.1998  &  CORADMO  drivers  projected  over 
time  and  technology-type. 

0.5.2  COCOMO-II.1998  comparison  with  final,  CORADMO  results 

Since  COCOMO-II.1998  only  calculates  the  effort  and  schedule  for  development,  a  second  set  of 
summary  charts  was  generated  so  the  COCOMO-II  model  results  could  be  easily  compared  to 
the  CORADMO  model  results.  The  second  set  of  charts  totals  effort  and  schedule  only  for  the 
Elaboration  and  Construction  stages.  Along  with  each  chart  are  copies  of  the  rows  of  the 
appropriate  data  from  "CoRADMo  Data"  sheet.  Figure  13  shows  one  of  the  comparisons  of 
COCOMO-II.1998  only  results  and  the  final  CORADMO  results. 
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Figure  13.  One  of  the  comparisons  of  COCOMO-IL1998  only  results  and  Final  Results 


Here,  both  the  COCOMO-II.1998  set  of  calculations  and  the  final  results  calculations  are  shown 
in  the  table  above  the  chart.  Again,  the  final  results  row’s  values  vdll  contain  the  results  based 
on  the  “current”  CORADMO  driver  values,  and  thus  may  have  changes  anytime  there  is  input  in 
the  “new”  row  of  the  drivers.  While  only  the  data  associated  with  the  top  row  of  the  table,  which 
contains  the  COCOMO-II.1998  calculation  results,  is  shown  in  the  chart,  the  final  results’  values 
are  evident  due  to  the  dashed  lines  appearing  in  the  chart. 

0.5.3  New/current  comparisons  with  default  driver  settings 

Finally,  a  third  set  of  charts  is  provide  to  provide  a  comparison  of  the  overall  effort  and  schedule 
results  using  the  default  driver  values  and  the  new/current  driver  values.  This  set  of  two  charts  is 
intended  to  assist  with  the  use  of  the  tool  in  sensitivity  analysis  studies.  Along  with  each  chart 
are  copies  of  the  rows  of  the  appropriate  data  from  “CoRADMo  Data”  sheet.  Figure  14  shows  a 
comparison  of  final  CORADMO  results  for  default  and  new  drivers  (with  the  only  driver  change 
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being  SIZE  (change  amount  reduced  by  50%).  If  there  has  been  no  change  in  any  of  the  drivers, 
the  lines  will  be  coincident  and  only  six  will  show  on  the  chart. 


Figure  14.  Comparisons  of  Effort  Final  Results  for  Default  and  New  Drivers 

Here,  both  the  default  and  new  final  results  calculations  are  shown  in  the  table  above  the  chart. 
Again,  the  new  final  results  row’s  values  will  contain  the  results  based  on  the  “current” 
CORADMO  driver  values,  and  thus  may  have  changes  anytime  there  is  input  in  the  “new”  row 
of  the  drivers.  While  only  the  data  associated  with  the  bottom  row  of  the  table,  which  contains 
the  new  calculation  results,  is  shown  in  the  chart,  the  default  results  values  are  evident  due  to  the 
solid  lines  appearing  in  the  chart. 
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0.6  Implementation 

The  workbook  has  six  protected  sheets  which  are  used  for  the  detailed  layout  of  the  drivers  to 
facilitate  the  graphing  shown  in  the  'Drivers’  sections.  These  sheets  also  include  sheets  for  the 
default  values  (i.e.  the  USC  Center  for  Software  Engineering  assessed  values)  of  the 
COCOMO-II.1998  and  CORADMO  drivers.  Figure  15  provides  details  on  the  protected 
implementation  sheets. 


Protected  implementation  support  worksheet .  . . 

COCOMO-II.1998  Modified  Data  for  Graphing  (tab ‘Cll  Mod4G'') . ; . .  . 

1.  Checks  for  new  values;  organizes  pararneters  into  single  page  for  check  purposes 

2  calculates  effort  and  schedule  according  to  the  CII-98  &  COSSEMO  rules . 

3  Organizes  Parameters  for  graphing  over  time  .  . . 

COCOMO-II.  1998  Original  Data  and  Graphs  (tab  .  . 

1  calculates  effort  and  schedule  according  to  the  CII-98  &  COSSEMO  rules  and  our  assessed  values 

2.  Organizes  Parameters  for  graphing  over  time 

3.  The  presentation  graphs  of  the  default  vaiues 
CoRADMo  Modified  Data  for  Graphing  (“RAD  ModD4G“  tab) 

1.  Checks  for  new  values;  organizes  parameters  into  single  page  for  check  purposes 

2.  Distributes  schedule  and  effort  over  stages  . . 

3’  Organizes  Parameters  for  compact  single  page  review  ; . . 

4.  Re-calculates  effort  and  schedule  according  to  the  Cjl-98  and  CORADMO  rules 

5.  :  Organizes  Parameters  for  graphing  over  time  . . . 

CoRADMo  Original  Data  and  Graphs  (“RAD  OD&G"  tab) . | 

1.  Organizes  default  parameters  into  single  page . : 

2.  Distributes  schedule  and  effort  over  stages  i 

3.  Organizes  Parameters  for  cornpact  single  page  rew^ 

4  Re-calculates  effort  and  schedule  according  to  the  cil-98  and  CORADMO  rules 

. 57  7  Organizes  Pararneters  for  graphjng  oyer  time  . ; .  . 

6.  Jhe  presentation  graphs  of  the  default  yaiues 


Official  CH-98  Scale  Factors  &  Effort  Multipliers  over  time  (“SF&EM-Otlnk^  . 

'  A  link  to  the  official  spread  sheet  providing  the  default  yaiues  i . 

iOfficiarCoRADMo  Schedule  (plus  effort  &  manpower)  Multipliers  over  time  (“SF&EM-OtInkd"  tab) 
A  link  to  the  official  spread  sheet  providing  the  default  values 


T7T;nyi=i  /  I  RAOModMg  /  RADOP^  /  MearteaCH  / 


Figure  15.  Details  on  the  protected  implementation  sheets 
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MISSION 

OF 

AFRL/INFORMATION DIRECTORATE  (IF) 

The  advancement  and  application  of  information  systems  science  and 
technology  for  aerospace  command  and  control  and  its  transition  to  air, 
space,  and  ground  systems  to  meet  customer  needs  in  the  areas  of  Global 
Awareness,  Dynamic  Planning  and  Execution,  and  Global  Information 
Exchange  is  the  focus  of  this  AFRL  organization.  The  directorate’s  areas 
of  investigation  include  a  broad  spectrum  of  information  and  fusion, 
communication,  collaborative  environment  and  modeling  and  simulation, 
defensive  information  warfare,  and  intelligent  information  systems 


technologies. 


